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Description 

[0001] This invention relates to methods of operation 
of computer systems, and more particularly to a method 
and system for managing the licensing of software ex- 5 
ecuted on computer systems. 

[8502] In U.S. Patent 4,937£63 (EP-A-0332304), is- 
sued to Robert, Chase and Schaf er and assigned to Dig- 
ital Equipment Corporation, the assignee of this inven- 
tion, a Software Licensing Management System is dis- io 
closed in which usage of licensed software may be mon- 
itored in a computer system to determine if a use is with- 
in the scope of a license. The system maintains a data- 
base of licenses for software products, delivering the li- 
cense document may be in the form of a network, or may is 
be a phone line using moderns, or may include physical 
delivery by disks or CD ROMs, for example. Likewise, 
the method of delivery of the software products being 
licensed, i.e., the applications programs 17 to be exe- 
cuted on the CPUs 1 6, is not material to the license man- 20 
agement facility of the invention; the products are deliv- 
ered by some appropriate means, e.g., the communica- 
tions link 30 and the networks 21 and 22, by CD ROMs 
or disks physically distributed, etc. 

[0003] Although shown in Figure 1 as operating on a 25 
distributed system, in the simplest case the license man- 
agement facility of the invention may be operated on a 
single CPU. The license management program 11 and 
the applications program 17 may be executing on the 
same CPU, in which case the license document would 30 
be stored in a database 23 as before, on this CPU, and 
the calls from the unit 1 8 to the license server would be 
local instead of RPCs. As in the distributed system, how- 
ever, the licensed product would still not have access to 
the license document, but instead could only make in- 35 
quires to the server program, even if all are executing 
on the same CPU. 

[0004L In operation of the distributed system of Fi gure 
1 , the producer 28 gives the issuer 25 authority to grant 
— licenses on its'Behatrftlle^r^uc^r^hiaissuer can b"ea~40 
singleentitywTfnjttipIe"^ 

gen eTator progranT^e, under control of a user (a per- 
sorj)T generate s a licens e (usually the result of negotia- 
tion ^weerrfhe user of program 26 and a user of the 
server 1 0). This license is called a product authori- 45 
z ation, and ins~trarism the servef 

10. The license management program in the server 10 
storeslhe prb^ucT use authorizatio n in th edatabase 23, 
and, if delegationjs an autho may distribute 

parts of the authorized use to the dele gatee servers 1 3, so 
where it is likewise stored in a database. The reaft er, ad- 
m in istrat ion 3jhe^^s^]sTon ly in response to inqu i ries 
from user nodes 16. When, execution of a program 17 
begins, the unit 18 is invoked to check on the availability 
ol a license for this particular node. The unit 18 sends 5$ 
(as by an RPC) a request to the license management 
program 14 (or 11 if there is no delegatee), where the 
product use authorization stored in database 23 is 



checked to see if use is authorized. If so, a return is sent 
to the user node 16, granting permission to continue. 
When the program 17 has finished executing, the unit 
1 8 again is invoked to signal to the license management 
program, again by an RPC, that the authorization is re- 
leased, so the license management program can take 
appropriate action, e.g., log the use in log 24, etc. 
[0005] To implement these operations, the license 
management program 11 or 14 contains several func- 
tions, including a client interface 31 , a database inter- 
face 32, a management interface 33, and an interserver 
interface 34 for communicating with the delegatees 13 
(if any). The client interface 31 , as described below, han- 
dles the requests received from the user nodes 16, and 
returns resulting from these requests. The database in- 
terface 32 handles the storing and retrieval of license 
information in the database 23, and logging license us- 
age activity to log 24, and retrieval of this data The man- 
agement interface 33 handles the tasks of receiving the 
product use authorizations from the issuer 25 and main- 
taining the database 23 via the database interface 32. 
The interserver interface 34 handles the task of commu- 
nicating with the delegatee servers 13, including trans- 
mitting the assigned parts of the product use authoriza- 
tions, or communicating with other license servers that 
may be separately executing the license management 
function; for example, calls for validating calling cards 
may be made to another such server If there are no del- 
egatees or no other license servers, then of course the 
interserver interface 34 has no function, and is idle. 
[0006] The license document or "product use author- 
ization" forming the basis for the license management 
activity of the program 11 on the server 10 may be illus- 
trated as a data structure containing the information set 
forth in Figure 2; in actual practice the product use au- 
thorization is preferably a more abstract data arrange- 
ment, not in such a rigidly structured format as illustrat- 
ed. For example, the product use authorization as well 
as similar documents stored in the database 23, or 
passed between components of the system of Figure 1 , 
may be of the so-called tag-length-value data format, 
where the data structure begins with an identifying tag 
(e.g., PUA or product use authorization) followed by a 
field giving the length, followed by the value itself (the 
content). One type of data treatment using this tag- 
length-value format is an international standard referred 
to as ASN.1 or Abstract Syntax Notation. In any event, 
the document 35 illustrated in Figure 2 is merely for dis- 
cussing the various items of data, rather than represent- 
ing the way the information is stored. Some of the fields 
shown here exist at some times and not others, and 
some are optional; the product use authorization may 
also include additional fields not shown or discussed 
here. Also it should be noted that copies of parts of this 
type of document are made for the delegatees, so this 
representation of Figure 2 is a composite of several doc- 
uments used in the system of Figure 1 The document 
35 includes fields 36 identifying the software product by 
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product name, producer, version numbers, release 
date, etc. The issuer 25 is identified in field 37, and the 
licensee (usually the owner of the license server 10) 
identified in field 38. The essential terms of the license 
grant are then defined in fields 40-46. The start date and 
end date are specified in fields 40; these store the exact 
time (date, hour, minute, second, etc.) when the license 
becomes valid and when it ends, so licenses may be 
granted to start at some future time and to end at a par- 
ticular time. Note that the previous practice has been to 
specify only the ending date, rather than also a start date 
as employed here. Each of the nodes, including issuer 
25, servers 10 and 13, and user nodes 16, maintain a 
time value by a local clock referenced to a standard, so 
inherent in the license management facility is the main- 
taining of a time standard to compare with the start and 
end date information in the fields 40. The units granted 
are specified in field 41 ; the units are an arbitrary quan- 
titative measure of program usage. In a delegatee serv- 
er 13, the units field 41 will have some subset of the 
units field in the original product use authorization. As 
units are granted to users 16 or delegated, the remain- 
ing units available for grant are indicated in a subfield 
42 in the copy of the document used by the server. The 
management policy occupies fields 43-46, and includes 
style, context, duration and LURDM (license use re- 
quirements determination method), as will be explained. 
The style field 43 specifies whether the licensed units 
are controlled by an "allocative" style or "consumptive" 
style, or some other "private" algorithm, where styles are 
ways used to account for the consumption or allocation 
of the units. The context field 44 specifies the location 
and environment in which product use or license man- 
agement occurs, i.e., a CPU or an individual user or a 
network, etc. Duration field 45 indicates whether the li- 
cense granted to a user is by assignment, by transac- 
tion, or immediate. The LURDM field 46 indicates the 
license use requirements determination method, in 
some cases using a license use requirements table 
(LURT) seen as field 47, as will be described. 
[0007] Additional fields 48-54 in the product use au- 
thorization 35 of Figure 2 define features such as dele- 
gation authorization, calling authorization, overdraft au- 
thorization, combination authorization, token, signature, 
checksum, etc. These will be described in the following 
paragraphs. 

[0008] If the delegation field 48 is true, a license serv- 
er 1 0 may distribute license units to multiple servers 1 3. 
A time limit may be imposed, i.e., units can be delegated 
to other hardware systems until they time out. Delega- 
tion allows an administrator to distribute units to improve 
response time and increase the resilience of the system. 
For example, the communication network 21 may in- 
clude a satellite link to a remote facility where the local 
server 13 has a number of clients or users 16, in which 
case the calls to the server 1 3 would be completed much 
quicker than would be the case if calls had to be made 
to the server 10. Also, delegation may be used as a 



method of allocating licensed units within a budget for 
administrative purposes. Usually the delegation author- 
ization is a feature that is priced by the issuer, i.e., a 
license granting 1000 units with delegation authoriza- 

5 tion is priced higher than without this authorization. 
[0009] The field 49 contains a calling authorization 
and/or a caller authorization. If the caller authorization 
in field 49 is true, the product is permitted to receive calls 
from other named products requesting use of the prod- 

10 uct, and if conditions are met (identified caller is author- 
ized) the server can grant a calling card, as described 
below. If the calling authorization is true, the product can 
make calls to other products. If neither is true, then the 
product can neither make or receive calls using the call- 
is ing card feature. Referring to Figure 1, if product 17a 
wishes to make a remote procedure call to a feature of 
product 17b running on a different user node 16, it 
makes a call to its server 13 including a request for a 
calling card, and, if permitted, the return to product 17a 

20 includes a calling card 49a. The product 1 7a then makes 
a call to product 1 7b in the usual manner of RPCs, send- 
ing along the calling card 49a, which the product 17b 
then verifies by a call to its server 13 before executing 
the called procedure and issuing its return to product 

25 17a. The feature of calling cards is important for distrib- 
uted applications. For example, if a product is able to 
execute faster in a distributed system by assigning tasks 
to other CPUs, then the issue is presented of which li- 
cense policy is needed, i.e., does every node executing 

30 a part of the task have to be licensed and consume or 
receive allocation of a unit, or just the one managing the 
task? This is resolved for most applications by use of 
this calling card concept. The product use authorization 
for such a product has the calling authorization field 49 

35 enabled, so calling cards can be issued. This feature is 
typically separately priced. 

[0010] The combination authorization field 50 of Fig- 
ure 2 determines whether or not license requests from 
a user node 1 6 can be satisfied by combining units from 

40 multiple product use authorizations. It may be advanta- 
geous to purchase licenses with different policy values, 
and use units from certain product use authorizations 
only for overflow or the like. Or, for other reasons, it may 
be advantageous to "borrow" and "lend" units among 

45 delegated servers or user nodes. This function is per- 
mitted or denied by the content of field 50. 
[0011] The overdraft field 51 determines whether or 
not a requested allocation from a user node 16 will be 
nevertheless granted, even though the units available 

50 field 42 is zero or too small to permit the requested use. 
Overdrafts can be unlimited, or a specific overdraft pool 
can be set up by a server 10, for a customer's internal 
administrative purposes. That is, the overdraft value 
may be unlimited in the original license, but limited or 

55 zero for internally distributed copies of the license. Thus, 
the product use authorization sent by the issuer 25 to 
the customer may have overdrafts permitted by the field 
51 , but the customer may deny overdraft permission for 
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its own budgeting purposes, in any event, if overdraft is 
permitted, additional fees have to be paid to the issuer 
at some accounting period, when the logged usage from 
log 24 indicates the available units have been exceed- 
ed. If overdraft is denied, then the units 18 of the user 
nodes making request allocations are structured to in- 
form the products 1 7 that a license grant is not available. 
The intent is not to prevent the application program from 
running; the license server merely informs the applica- 
tion whether or not the license manager determines that 
it is authorized to run. The application can itself be struc- 
tured to shut itself down if not authorized to run, or it can 
be structured to shut down certain functions (e.g., ability 
to save files, ability to print, etc.), or it can be structured 
to continue in a fully functional manner. The purpose of 
the license management facility is not that of enforce- 
ment, nor that of "copy protection", but instead is merely 
that of license management. 

[0012] An optional token field 52 is available in the 
product use authorization 35 of Figure 2. This field can 
contain comments or other information desired by the 
issuer or user. For example, a telephone support 
number may be included in the token field, then when 
the product 17 shows its "help screen" the number is 
inserted. This number would be part of the argument, i. 
e., data transmitted to the user node 16, when the server 
10 makes a return following a request allocation mes- 
sage from the user. This field may also be used to store 
information used in a "private" style, where the informa- 
tion from this field returned to the user node is employed 
by the application program 1 7 or the stub 1 9 to deter- 
mine if the application can be activated. 
[0013] The signature field 53 in the product use au- 
thorization 35 is a part of a validation mechanism which 
provides important features. This field contains a digital 
signature encoded to reflect the data in the license itself, 
as well as other encoding methods not known to cus- 
tomers, so it cannot be duplicated unless the encoding 
algorithm is known. In a preferred embodiment, a so- 
called "public/private key" system of encoding is used 
for the signature field 53. The encoding algorithm used 
to generate the signature 53 is known to the issuer 25, 
using a private key, and anyone knowing the public key 
can decode the signature to determine if it is valid but 
cannot determine the encoding algorithm so it cannot 
produce a forged signature. So, if the server 10 knows 
the public key which is unique to the issuer 25, it can 
determine if a license document 35 is genuine, but it 
cannot itself generate license documents However, if 
the server possesses a valid license document that 
gives it the right to delegate, then it will be assigned its 
own private key (different from all other issuers or serv- 
ers) and its delegatees 13 will be able lo determine if a 
valid delegated license is delivered to them as they will 
be given the public key for the servers 13. The field 53 
will thus contain both the original signature from the is- 
suer 25 and the license server's signature when deliv- 
ered to a delegatee 1 3. The decoding algorithm using a 



public key for any signatures is thus used by the license 
server 10 or delegatee 13 to make sure a product use 
authorization 35 is authentic before it is stored in the 
database 23. Related to the digital signature 53 is a 

5 checksum field 54, which merely encodes a value relat- 
ed by some known algorithm to the data in the product 
use authorization 35 itself. This field may be used mere- 
ly to check for corruption of the data as it is stored, re- 
called, and transmitted within the system. That is, the 

10 checksum is used for data validation rather than secu- 
rity. 

[0014] Two concepts central to the license manage- 
ment system implemented using the license document 
or product use authorization 35 of Figure 2 are the "li- 

^5 cense units", specified in field 41 or 42 and the "context", 
specified in field 44. License units are an abstract nu- 
merical measure of product use allowed by the license. 
When a product 1 7 (or a function or feature of a product) 
makes a license-checking request, the license manage- 

20 ment program 11 on server 10 computes how many li- 
cense units are required to authorize this particular use 
of the product, and this is the license units requirement, 
in some cases using the LURDM field 46. A "context" is 
a set of tagged values which define the location and en- 

25 vironment in which product use or license management 
occurs. Context values may be specified in field 44 of 
the product use authorization 35 of Figure 2 to restrict 
the environments in which the license may be managed 
and in which product use may occur. A context template 

30 may also be specified in the field 44 to indicate which 
parts of the complete context of product use (sub-con- 
texts) are significant in differentiating product uses for 
the purposes of unit allocation; when this is specified, it 
allows separate product uses to share license units in a 

35 controlled way. 

[0015] The two general types of policies specified in 
field 43 are al locative and consumptive. An allocative 
policy grants to the holder a specific number of license 
units (field 41 ) and specifies the policy which must be 

40 used to account for the allocation of these units. A soft- 
ware product 17 which is being managed by an alloca- 
tive license will require verification that the appropriate 
number of license units have been allocated to it prior 
to performing services to the user. Typically, this alloca- 

45 tion of units occurs either at the time of activation of the 
product 1 7 or at the time that product use is enabled on 
a particular platform (user CPU 16). The units typically 
remain allocated to the product 17 throughout the period 
that the product is running or is enabled to run. Upon 

50 termination of processing or disabling, the allocated 
units are deallocated and made available for allocation 
to other instances of the software product 17 (other us- 
ers 1 6 activating the product). In general, as long as any 
license units remain unallocated in field 42, the holder 

55 of the license is contractually authorized to increase his 
utilization of the licensed product. The usage does not 
deplete the license, however, as the units are returned 
to the units-available field 42 after a user is finished, and 
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can be granted again to another user. 
[001 6] A consumptive unit based license, indicated in 
policy field 43, grants to the holder a specific number of 
initial license units (from field 42) and specifies the pol- 
icy used to account for the consumption of those units. 
A software product 1 7 which is being managed by a con- 
sumptive license will cause an appropriate number of 
license units to be consumed to reflect the services pro- 
vided by the product. Once consumed, units cannot be 
reused. Thus, the number of units available for future 
use declines upon every use of the licensed software 
product 17. This may also be referred to as a "metered" 
policy, being conceptually similar to measured con- 
sumption of electricity, water, etc. When the number of 
available units in field 42 reaches zero, the license may 
require that further use of the product is prohibited, or, 
the agreement may permit continued decrementing of 
the number of available units; the result is the accumu- 
lation of a negative number of available units in the field 
42. It is anticipated that most consumptive unit based 
licenses will consider negative units to represent an ob- 
ligation of the license holder to pay the license issuer 
25. The transaction log 24 maintains an audit trail for 
providing a record of the units used in a consumptive 
license. 

[0017] Referring to Figure 3, the major elements of the 
management policy are set forth in a table, where the 
possible entries for the fields 43, 44, 45 and 46 are listed. 
For the style entry 43, the possibilities are allocative and 
consumptive as just described, plus a category called 
"private" which represents a style of management un- 
defined at present but instead to be created especially 
for a given product, using its own unique algorithm. It is 
expected that most licenses may be administered using 
the named alternatives of Figure 3, but to allow for future 
expansion to include alternatives not presently envi- 
sioned, or to permit special circumstances for unique 
software, the "private" choices are included, which 
merely mean that the product 17 will generate its own 
conditions of use. It is important to note that, except for 
the "private - alternative, the license management is to- 
tally in control of the license management program 11 
on the license server 10 (ordelegatee 13), rather than 
at the product 17. All the product 17 does, via the unit 
18, is to make the request inquiry to the server 10 via 
the client interface 31 , and report when finished. 
[0018] The context field 44 specifies those compo- 
nents (sub-contexts) of the execution-context name 
which should be used in determining if unit allocations 
are required. License data is always used or allocated 
within, or for the benefit of, some named licensing con- 
text, and context can include "platform contexts" and 
"application contexts". Plalform contexts are such 
things as a specific network, an execution domain, a 
login domain, a node, a process ID or a process family, 
a user name, a product name, an operating system, a 
specific hardware platform, as listed in Figure 3 Appli- 
cations contexts are information supplied from the ap- 



plication (the product 17), such as may be used in a "pri- 
vate" method of determining license availability. The 
context name can use several of these, in which case 
the context name is constructed by concatenating the 

s values of all subcontexts into a single context name, e. 
g., a VAX 3100 platform using VMS operating system. 
[0019] The duration field 45 defines the duration of an 
allocation of license units to a specific context or the du- 
ration of the period which defines a valid consumptive 

io use. For durations of type "Assignment," the specifica- 
tion of a reassignment constraint is also provided for, as 
discussed below. There are three types of duration, 
these being "transaction," "assignment" and "immedi- 
ate" as seen in Figure 3. 

15 [0020] The transaction duration type, when specified 
for an allocative policy, indicates that license units 
should be allocated to the specified context upon receipt 
of a license request and that those units should be deal- 
located and returned to the pool of available units upon 

20 receipt of a corresponding license release from a user 
node 1 6. Abnormal termination of the process or context 
having made the original license request will be seman- 
tical ly equivalent to a license release. On the other hand, 
when specified for a consumptive policy, this duration 

25 type indicates that license units should be allocated to 
the specified context upon receipt of a license request 
and permanently removed from the available units pool 
(field 42) upon receipt of a license release which reflects 
successful completion of the transaction. Upon receipt 

30 of a license release which carries an error status or upon 
abnormal termination of the processor context having 
made the original license request, the allocated units will 
be deallocated and returned to the pool of available units 
(field 42). 

35 [0021] The assignment duration type in Figure 3 (field 
45 of Figure 2) imposes the constraint that the required 
units must have been previously assigned to a specific 
context. The sub-contexts which must be specified in 
the assignment are those given in the context-template. 

40 A "reassignment constraint" may be imposed, and this 
is a limitation on how soon a reassignment can be made. 
For example, a reassignment constraint of 30-days 
would require that units assigned to a specific context 
could not be reassigned more often than every 30-days; 

45 this would prevent skirting the intent of the license by 
merely reassigning units whenever a user of another 
context made a request allocation call for the product. 
Related to this assignment constraint, a "reallocation 
limit" may also be imposed, to state the minimum dura- 

50 tion of an allocation; where there is a context template 
of process, the intent is to count the number of uses of 
the software product at a given time, but where software 
runs in batch rather than interactive mode it may run 
very quickly on a powerful machine, so a very few con 

55 current uses may permit almost unlimited usage - by im- 
posing a reallocation constraint of some time period, this 
manner of skirting the intent of the license may be con- 
strained. 
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[0022] The immediate duration type (field 45 of Figure 
2) is used to indicate that the allocation or consumption 
of an appropriate number of license units from the pool 
of available units (field 42) should be performed imme- 
diately upon receipt of a license request. Receipt of li- 
cense release or abnormal terminations will then have 
no impact on the license management system. When 
specified as the duration for an a I locative policy, the ef- 
fect will be simply to check if an appropriate number of 
license units are available at the time of a license re- 
quest. When specified as the duration for a consumptive 
policy, the effect will be to deduct the appropriate 
number of license units from the available pool at the 
time of a license request, and, thereafter, abnormal ter- 
mination, such as a fault at the user CPU 1 6 or failure 
of the network link, will not reinstate the units. 
[0023] The LURDM or license unit requirement deter- 
mination method, field 46, has the alternatives seen in 
Figure 3 and stores information used in calculating the 
number of units that should be allocated or consumed 
in response to a license request. If this field specifies a 
table lookup kind, this means license unit requirements 
are to be determined by lookup in the LURT (field 47) 
which is associated with the current license. If a constant 
kind is specified, this indicates that the license units re- 
quirements are constant for all contexts on which the 
licensed product or product feature may run. A private 
LURDM specifies that the license unit requirements are 
to be determined by the licensed product 1 7, not by the 
license management facility 11 . The license unit require- 
ments tables (LURTs) provide a means by which issuers 
of licenses can store information describing the relation 
between context (or row selector) and unit require- 
ments. The license units requirements determination 
method (LURDM) must specify table lookup" for the 
LURT to be used, and if so a row selector must be spec- 
ified, where a valid row selector is any subcontext, e.g. , 
platform ID, user name, time of day, etc. An example of 
an LURT fragment is shown in Figure 4, illustrating the 
license unit requirements table mechanism. In this ex- 
ample, the row selector is 'platform-ID - so the platform- 
ID value determines which row is used. The issuer of 
this LURT of Figure 4 has established three unit require- 
ment tiers for use in determining the unit requirements 
for that issuer's products. The reason for the tiers is not 
mandated by the license management system, but the 
issuer 25 (actually the user of the program 26) would 
probably be establishing three pricing tiers, each reflect- 
ing a different perspective on the relative utility of differ- 
ent platforms in supporting the use of various classes of 
product 17. The first column in Figure 4, Column A, 
specifies the use requirements for a class of products 
whose utility is highly sensitive to the characteristics of 
the specific platform on which they are run. This can be 
seen by observing thai the unit requirements are differ- 
ent for every row in Column A. Products which use the 
second column (Column B) appear to have a utility 
which is more related to the class of platform on which 



they run. This is indicated by the fact that all the PC plat- 
forms share a single value which is different from that 
assigned to the VAX platform. The final column (Column 
C) is for use with a class of products which is only sup- 
5 ported on the VAX platform. Figure 4 is of course merely 
an example, and the actual LURT created by the license 
document generator 26 and stored in the license data- 
base 23 (as field 47 of the product use authorization 35) 
can be of any content of this general format, as desired 
io by the license issuer. 

[0024] Instead of always selecting the rows in LURT 
tables according to the platform ID of the execution plat- 
form, in order to handle the breadth of business practic- 
es that need to be supported by the license manage- 
rs ment facility, the LURT mechanism is extended by pro- 
viding a "row selector - attribute in the LURT class struc- 
ture. No default is provided although it is expected that 
the normal value for the row selector attribute will be 
■platform ID." 

20 [0025] In the system of patent 4,937,863, a concept 
similar to that of the LURT of Figure 4 was provided, with 
rows selected by the platform ID and columns selected 
by some arbitrary means, typically according to product 
type. The system of this invention allows flexibility in the 

25 selection of both LURT row and column while continuing 
to provide backwards compatibility for licenses defined 
within the constraints of patent 4,937,863. 
[0026] Some examples will illustrate potential uses for 
the row selector attribute. A customer may only want to 

30 pay for the use of a product during one or two months 
of the year; the product may be FORTRAN and the rea- 
son for this request may be that the company has a fairly 
stable set of FORTRAN subroutines that are given reg- 
ular "annual maintenance" only during the months of 

35 May and June. To handle this customer's needs, the 
FORTFtAN product would generate an application sub- 
context which would contain a value representing the 
month of the year. Then, a LURT table would be defined 
with twelve rows, one for each month of the year. In 

40 some column, probably column A, a negative one (-1) 
would be placed in each month except for May and 
June. These two months would contain some positive 
number. The product use authorization would then have 
a LURDM field specifying a LURT for use to determine 

45 the units requirement, and would name this custom 
LURT table. The effect would be that the PUA could only 
be used during the months of May and June since neg- 
ative one is interpreted by license managers to mean 
"use not authorized." This mechanism could also be 

50 used to do "time of day" charging Perhaps charging 
fewer units per use at night than during the day. Also, if 
a subcontext was used that contained a year value, a 
type of license would be provided that varied in its unit 
requirements as time passed. For instance, it might start 

55 by costing 10-units per use in 1991 but then cost one 
unit less every year as time passed, eventually getting 
to the point where the unit requirement was zero. 
[0027] Another example is font names. A specific cus- 
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tomer may purchase a license giving it the right to con- 
current use of 100-units of a large font collection; some 
of the fonts may cost more to use than others. For in- 
stance, Times Roman might cost 10-units per use while 
New Century Schoolbook costs 20-units per use. The 
problem is, of course, making sure that charges are 
properly made. The solution is to build a LURT table with 
a specified application subcontext as its row selector. A 
row is then created for each font in the collection and in 
Column A of the LURT, the number of units required to 
pay for use of the font would be specified. The print serv- 
er would then specify the name of a font as the value of 
the application subcontext whenever it does an 
lm_request_alIocation() calk This will allow charges to 
be varied according to font name. 
[0028] A further example is memory size. Some prod- 
ucts are more or less valuable depending on the size of 
memory available to support them. A software vendor 
wishing to determine unit requirements based on mem- 
ory size will be able to do so by building LURTT tables 
with rows for each reasonable increment of memory 
(probably 1 -megabyte increments). Their applications 
would then sense memory size (using some mechanism 
not part of the license management facility) and pass a 
rounded memory size value to the license manager in a 
private context. 

[0029] Other examples are environment and operat- 
ing system. Some products may be valued differently 
depending on whether they are being run in an interac- 
tive mode or in batch. This can be accomplished by 
building LURT rows for each of the standard platform 
subcontexts that specify environment. Regarding oper- 
ating system, it has been considered desirable by many 
to have a single product use authorization permit the use 
of a product on any number of operating systems, this 
conflicts with some vendors policies who do not want to 
have to create a single price for a product that applies 
to all operating systems. Thus, if an operating system 
independent license were offered for a C compiler, the 
price would be the same on MS-DOS, VMS, and/or 
UNIX. Clearly, it can be argued that the value of many 
products is, in part, dependent on the operating system 
that supports them. By using a row selector of operating 
system (one of the standard platform subcontexts), li- 
cense designers could, intact, require different numbers 
of units for each operating system. However, it might be 
more desirable to base the row selection on a private 
application subcontext that normally had the same value 
as the operating system subcontext The reason for this 
is that the license, designer might want to provide a de- 
fault value for operating system names that were un- 
known at the time the LURT rows were defined. If this 
is the case, the product would contain a list of known 
operating systems and pass the subcontext value of 
"Unknown" when appropriate The LURT row for "Un- 
known" would either contain a negative one (-1 ) to indi- 
cate that this operating system was unsupported or it 
would contain some default unit requirement. 



[0030] Another example is variable pricing within a 
group. One of the problems with a "group" license is that 
there is only one unit requirements field on the PUA for 
a group. Thus, all members of the group share a single 

5 unit requirement. However, in those cases were all 
members of the group can be appropriately licensed 
with a constant unit requirement yet it is desired to 
charge different amounts for the use of each group 
member, a LURT can be built that has rows defined for 

10 each group member. The row selector for such a group 
would be the standard platform subcontext "product 
name.' 

[0031] Many different types of license can be created 
using different combinations of contexts, duration and 

15 policy from the table of Figure 3. As examples, the fol- 
lowing paragraphs show some traditional licensing 
styles which can be implemented using the appropriate 
values of the product use authorization fields 43-46. 
[0032] A "system license' as it is traditionally desig- 

20 nated is a license which allows unlimited use of a prod- 
uct on a single hardware system. The correct number 
of units must be allocated to the processor in advance 
and then an unlimited product use is available to users 
of the system. The product use authorization would 

25 have in the context field 44 a context template for a node 
name, the duration field would be "assignment" and the 
policy style field 43 would be 'al locative". 
[0033] A "concurrent use" license is one that limits the 
number of simultaneous uses of a licensed product. 

30 Concurrent use license units are only allocated when 
the product is being used and each simultaneous user 
of the licensed product requires their own units. In this 
case the context template, field 44, is a process ID, the 
duration field is "transaction" and the policy style 43 is 

35 ■allocative". 

[0034] A "personal use" license is one that limits the 
number of named users of a licensed product. This style 
of licensing guarantees the members of a list of users 
access to a product. Associated with a personal use 

40 type of product use authorization there is a list of regis- 
tered users. The administrator is able to assign these 
users as required up to the limit imposed by the product 
use authorization; the number of units assigned to each 
user is indicated by the LURDM. It may be a constant 

45 or it may vary as specrfied in a LURT The context tem- 
plate is "user name", the duration is "assignment", and 
the policy is "allocative". 

[0035] A "site license* is one that limits the use of a 
licensed product to a physical site. Here the product use 

50 authorization contains for the context template either 
"network name" or "domain name", the duration is "as- 
signment" and the policy style field 43 is "allocative". 
[0036] Generally, a license to use a software product 
is priced according to how much benefit can be gained 

55 from using the product, which is related to the capacity 
of the machine it will run on. A license for unlimited use 
on a large platform such as a mainframe, where there 
could be thousands of potential users at terminals, 
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would be priced at a high level. Here the style would be 
■allocative", the context template = "node - , the duration 
= "assignment" and the LURDM may be "Column A" - 
the units, however, would be large, e.g., 1000. At the 
other end of the scale would be a license for use on a 
single personal computer, where the field values would 
be the same as for the mainframe except the units would 
be "1 ". If a customer wanted to make the product avail- 
able on the mainframe but yet limit the cost, he could 
perhaps get a license that would allow only five users at 
any given time to use the product; here the fields in the 
product use authorization would be: units - 5; style - 
allocative; context template = process; duration = trans- 
action; LURDM = constant, 1-unit. This would still be 
priced fairly high since a large number of users may ac- 
tually use the product if a session of use was short. A 
lower price would probably be available for a personal 
use license where only five named persons could use 
the product, these being identified only in the license 
server 10, not named by the license issuer 25. Here the 
fields in the product use authorization are: units = 5; 
style = allocative; context template = user name; dura- 
tion = transaction; LURDM = constant, 1 -unit. 
[0037] An additional feature that may be provided for 
in the product use authorization 35 is license combina- 
tion. Where there are multiple authorizations for a prod- 
uct, license checking requests sent by user nodes 1 6 
may be satisfied by combining units from multiple au- 
thorizations. Individual product use authorizations may 
prohibit combined use. Thus, a licensee may have a li- 
cense to use a product 17 on an allocative basis for a 
certain number of units and on a consumptive basis for 
another number of units (this may be attractive from pric- 
ing standpoint); there might not be enough units availa- 
ble for a particular context from one of these licenses, 
so some units may be "borrowed" from the other license 
(product use authorization), in which case a combina- 
tion is made. 

[0038] The interface between the program executing 
on the client or user 16 and the license server 10 or its 
delegatees 13 includes basically three procedure calls: 
a request allocation, a release allocation and a query 
allocation. Figure 5 illustrates in flowchart form some of 
the events occurring in this client interface. The request 
allocation is the basic license checking function, a pro- 
cedure call invoked when a software product 1 7 is being 
instantiated, functioning to request an allocation of li- 
cense units, with the return being a grant or refusal to 
grant Note that a product may use request allocation 
calls at a number of points in executing a program, rath- 
er than only upon start-up; for example, a request allo- 
cation may be sent when making use of some particular 
feature such a special graphics package or the like. The 
release allocation call is invoked when the user no long- 
er needs the allocation, e.g., the task is finished, and 
this return is often merely an acknowledge; if the style 
is consumptive, the caller has the opportunity via the re- 
lease allocation call to influence the number of units con- 



sumed, e.g., decrease the number due to some event. 
The query allocation call is invoked by the user to obtain 
information about an existing allocation, or to obtain a 
calling card, as will be described. 

5 [0039] The request allocation, referred to as 
lm_request_allocation(), is a request that license units 
be allocated to the current context. This function returns 
a grant or denial status that can be used by the applica- 
tion programmer to decide whether to permit use of the 

10 product or product feature. The status is based on the 
existence of an appropriate product use authorization 
and any license management policies which may be as- 
sociated with that product use authorization. License 
units will be allocated or consumed, if available, accord- 

15 ing to the policy statement found on the appropriate 
product use authorization. The product would normally 
call this function before use of a licensed product or 
product feature. The function will not cause the prod- 
uct's execution to be terminated should the request fail. 

20 The decision of what to do in case of failure to obtain 
allocation of license units is up to the programmer. The 
arguments in a request allocation call are the product 
name, producer name, version, release date, and re- 
quest extension. The product name, producer name, 

25 version and release date are the name of the software 
product, name of producer, version number and release 
date for specifically identifying the product which the us- 
er is requesting an allocation be made. The request ex- 
tension argument is an object describing extended at- 

30 tributes of the request, such as units required, LURT col- 
umn, private context, and comment. The results sent 
back to the calling node are a return code, indicating 
whether the function succeeded and, if not, why not, and 
a grant handle, returned if the function completes suc- 

35 cessfully, giving an identifying handle for this grant so it 
can be referred to in a subsequent release allocation 
call or query allocation call, for example. 
[0040] The release allocation, referred to as 
lm_release_aIlocation(), is an indication from a user to 

40 the license manager to release or consume units previ- 
ously allocated. This function releases an allocation 
grant made in response to a prior call to request alloca- 
tion. Upon release, the license management style 38 de- 
termines whether the units should be returned to the 

45 pool of available units or consumed. If the caller had 
specified a request extension on the earlier call to re- 
quest allocation which contained a units-required-at- 
tribute, and the number of units requested at that time 
are not the number of units that should be consumed for 

50 the completed operation, the caller should state with the 
units-consumed argument how many units should be 
consumed. The arguments of the release allocation are: 
grant handle, units consumed, and comment. The grant 
handle identifies the allocation grant created by a pre- 
ss vious call to request allocation. The units-consumed ar- 
gument identifies the number of units which should be 
consumed if the license policy is consumptive; this ar- 
gument should only be used in combination with an ear- 
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Her call to request allocation which specified a units re- 
quirement in a request extension. Omission of this ar- 
gument indicates that the number of units to be con- 
sumed is the same as the number allocated previously. 
The comment argument is a comment which will be writ- 
ten to the log file 24 if release units are from a consump- 
tive style license or if logging is enabled. The result is a 
return code indicating if the function succeeded, and, if 
not, why not. 

[0041 ] The query al location , or \m_query_alk>cat\or\(), 
is used by licensed products which have received allo- 
cations by a previous request allocation call. The query 
is to obtain information from the server 1 0 or delegatee 
server 13 about the nature of the grant that has been 
made to the user and the license data used in making 
the grant, or to obtain a calling card (i.e., a request that 
a calling card be issued). Typically, the item read by this 
query function is the token field 52 which contains arbi- 
trary information encoded by the license issuer and 
which may be interpreted as required by the stub 1 9 for 
the licensed product software 17, usually when a "pri- 
vate" allocation style or context is being employed. The 
arguments in this procedure call are the grant handle, 
and the subject. The grant handle identifies the alloca- 
tion grant created by a previous call to request alloca- 
tion. The subject argument is either "product use author- 
ization" or "calling card request"; if the former then the 
result will contain a public copy of the product use au- 
thorization. If this argument is a calling card request and 
a calling card which matches the previous constraints 
specified in that request can be made available, the re- 
sult will contain a calling card. If the subject argument 
is omitted, the result will contain an instance of the allo- 
cation. The results of the query allocation call are (1 ) a 
return code, indicating whether the function succeeded, 
and, if not, why not, and (2) a result, which is either an 
allocation, a product use authorization or a calling card, 
depending on type and presence of the subject argu- 
ment. 

[0042] Referring to Figure 5, the flow chart shows the 
actions at the client in its interface with the server When 
the software product 17 is to be invoked, the unit 18 is 
first executed as indicated by the block 60, and the first 
action is to make a request allocation call via the stub 
19, indicated by the block 61 The client waits for a re- 
turn, indicated by the loop 62, and when a return is re- 
ceived it is checked to see if it is a grant, at decision 
block 63. If not, the error code in the return is checked 
at block 64, and if a return code indicates a retry is pos- 
sible, block 65, control passes back to the beginning, 
but if no retry is to be made then execution is terminated. 
If the policy is to allow use of the product 17 without a 
license grant, this function is separately accounted for. 
If the decision point 63 indicates a grant was made, the 
grant handle is stored, block 66, for later reference. The 
program 1 7 is then entered for the main activities intend- 
ed by the user During this execution of product 17, or 
before or after, a query allocation call can be made, 



block 67, though this is optional and in most cases not 
needed. When execution of the program 17 is complet- 
ed, the grant handle is retrieved, block 68, and a release 
allocation call is made, block 69. A loop 70 indicates 

s waiting for the return from the server, and when the re- 
turn received it is checked for an error code as before, 
and a retry may be appropriate. If the release is suc- 
cessfully acknowledged, the program exits. 
[0043] Referring to Figure 6, the actions of the server 

io 1 o or delegatee server 1 3 in executing the license man- 
agement program 11 or 14, for the client interface, are 
illustrated in flow diagram form. A loop is shown where 
the server program is checking for receipt of a request, 
release or query call from its clients. The call would be 

15 a remote procedure call as discussed above, and would 
be a message communicated by a network, for exam- 
ple. This loop shows the decision blocks 71, 72 and 73. 
If a release allocation call is received, a list of products 
for which authorizations are stored is scanned, block 74, 

20 and compared to the product identity given in the argu- 
ment of the received call, block 75. If there is no match, 
an error code is returned to the client, block 76, and con- 
trol goes back to the initial loop. If the product is found, 
the authorization is retrieved from the database 23, 

25 block 77 (there may be more than one authorization for 
a given product, in which case all would be retrieved, 
but only one will be referred to here) and all of the infor- 
mation is matched and the calculations made depend- 
ing upon the management policy of Figures 3 and 4, in- 

30 dicated by the decision block 78. If a grant can be made, 
it is returned as indicated at block 79, or if not an error 
code is returned, block 80. If a release allocation call is 
received, indicated by a positive at the decision block 
72 , the grant handle in the argument is checked for va- 

35 ijdrty at block 81 . If no match is found, an error code is 
returned, block 82, and control passes back to the initial 
loop. If the handle is valid, the authorization for this prod- 
uct is retrieved from the database 23 at block 83, and 
updated as indicated by the block 84. For example, if 
the license management style is al locative, the units are 
returned to the available pool. Or, in some cases, no up- 
date is needed. The authorization is stored again in the 
database, block 85, and a return made to the client, 
biock 86, before control passes back to the initial loop. 

^5 |f the decision block 73 indicates that a query allocation 
call is received, again the grant handle is checked at 
block 87, and an error code returned at block 88 if not 
valid. If the grant handle matches, the authorization is 
retrieved from the database 23, at block 89, and a return 

50 is made to the client giving the requested information in 
the argument, block 90. 

[0044] The basic allocation algorithm used in the em 
bodiment of the license management system herein de- 
scribed, and implemented in the method of Figures 5 
55 and 6, is very simple and can handle a very large pro- 
portion of known license unit allocation problems How- 
ever, it should be recognized that a more elaborate and 
expanded algorithm could be incorporated. Additions 
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could be made in efforts to extend the allocation algo- 
rithm so that it would have specific support for optimizing 
unit allocation in a wider variety of situations. Particular- 
ly, sources of non-optimal allocations occurring when 
using the basic allocation algorithm are those that arise 
from combination and reservation handling. 
[0045] The first step is formation of full context. The 
client stub 19 is responsible for collecting all specified 
platform and application subcontexts from the execution 
environment of the product 1 7 and forwarding these col- 
lected subcontexts to the license management server 
1 3 or 10. The collection of subcontexts is referred to as 
the "full context" for a particular license unit allocation 
request. 

[0046] The next step is retrieval of the context tem- 
plate. When the license manager receives an 
lm_request_alIocatk>n(), it will look in its list of available 
product use authorizations (PUA) to determine if any of 
them conform to the product identifier provided in the 
!m_request_al/ocation() call. The product identifier is 
composed of: product name, producer, version, release 
date. If any match is found, the license manager will ex- 
tract from the matching PUA the context template. This 
template is composed of a list of subcontexts that are 
relevant to the process of determining unit require- 
ments. Thus, a context template may indicate that the 
node-ID subcontext of a specific full context is of interest 
for the purposes of unit allocation. The context template 
would not specify any specific value for the node-ID; 
rather, it simply says that node-ID should be used in 
making the allocation computation. 
[0047] The next step is masking the full context. Hav- 
ing retrieved the context template, the license manager 
will then construct an "allocation context" by filtering the 
full context to remove all subcontexts which are not list- 
ed in the context template. This allocation context is the 
context to be used in determining allocation require- 
ments. 

[0048] Then follows the step of determining if the re- 
quest is new. The license manager maintains for each 
product use authorization a dynamic table which in- 
cludes the allocation contexts of all outstanding alloca- 
tions for that PUA (i.e., allocations that have been grant- 
ed but have not yet been released). Associated with 
each entry in this table is some bookkeeping information 
which records the number of units allocated, the full con- 
text, etc. To determine if a recent Im_request_alhcation 
() requires an allocation of units to be made, the license 
manager compares the new allocation context with all 
those allocation contexts in the table of outstanding al- 
locations and determines if an allocation has already 
been made to the allocation context. If the new alloca- 
tion context does not already exist in the table, an at- 
tempt will be made to allocate the appropriate number 
of units depending on the values contained in the 
LURDM structure of the PUA and any LUKTs that might 
be required If an allocation context similar to that spec- 
ified in the new allocation request does exist in the table, 



the license manager will verify that the number of units 
previously allocated are equal to or greater than the 
number of units which would need to be allocated to sat- 
isfy the new allocation request. If so, the license man- 

5 ager will return a grant handle to the application which 
indicates that the allocation has been made (i.e., it is a 
"shared allocation" - the allocated units are shared be- 
tween two requests.) If not, the license manager will at- 
tempt to allocate a number of units equal to the differ- 

10 ence between the number previously allocated and the 
number of units required. 

[0049] The step of releasing allocations (Fig. 6, blocks 
84-85) occurs when the license manager receives an 
lm_release_allocation() call; it will remove the record in 

*s its dynamic allocation table that corresponds to the al- 
location to be released. Having done this, the license 
manager will then determine if the allocation to be re- 
moved is being shared by any other allocation context. 
If so, the units associated with the allocation being re- 

20 leased will not be released. They will remain allocated 
to the remaining allocation contexts. Some of the units 
might be released if the license manager determines 
that the number of allocated units exceeds the number 
needed to satisfy the outstanding allocation contexts. If 

25 this is the case, the license manager will "trim" the 
number of allocated units to an appropriate level. 
[0050] In summary, the two things that make this al- 
gorithm work are (1 ) the basic rule that no more than 
one allocation will be made to any single allocation con- 

30 text, and (2) the use of the context template to make 
otherwise dissimilar full contexts appear to be similar for 
the purposes of allocation. 

[0051] The license designer's task, when defining ba- 
sic policy, is then to determine which contexts should 

35 appear to be the same to the license manager. If the 
license designer decides that all contexts on a single 
node should look the same (context template = node- 
ID), then any requests that come from that node will all 
share allocations. On the other hand, a decision that all 

40 contexts should be unique (i.e., context template = proc- 
ess-ID) will mean that allocations are never shared, and 
stores a unit value indicating the number of licensing 
units for each product When a user wishes to use a li- 
censed product, a message is sent to the central license 

45 management facility requesting a license grant. In re- 
sponse to this message, the facility accesses the data- 
base to see if a license exists for this product, and, if so, 
whether units may be allocated to the user, depending 
upon the user's characteristics, such as the configura- 

50 tion of the platform (CPU) which will execute the soft- 
ware product. If the license management facility deter- 
mines that a license can be granted, it sends a message 
to the user giving permission to proceed with activation 
of the product. If not, the message denies permission. 

55 [0052] While the concepts disclosed in the patent 
4,937,863 are widely applicable, and indeed are em- 
ployed in the present invention, there are additional 
functions and alternatives that are needed in some ap- 
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plications. For example, the license management sys- 
tem should allow for simultaneous use of a wide variety 
of different licensing alternatives, instead of being rigidly 
structured to permit only one or only a few. When nego- 
tiating licenses with users, vendors should have availa- 
ble a wide variety of terms and conditions, even though 
a given vendor may decide to narrow the selection down 
to a small number. For example, a software product may 
be licensed to a single individual for use on a single 
CPU, or to an organization for use by anyone on a net- 
work, or for use by any users at terminals in a cluster, 
or only for calls from another specific licensed product, 
or any of a large number of other alternatives. A vendor 
may have a large number of products, some sold under 
one type of license and some under others, or a product 
may be a composite of a number of features from one 
or more vendors having different license policies and 
prices; it would be preferable to use the same license 
management system for all such products. 
[0053] Distributed computing systems present addi- 
tional licensing issues. A distributed system includes a 
number of processor nodes tied together in a network 
of servers and clients. Each node is a processor which 
may execute programs locally, and may also execute 
programs or features (subparts of programs) via the net- 
work. A program executing on one node may make re- 
mote procedure calls to procedures or programs on oth- 
er nodes. In this case, some provision need be made 
for defining a license permitting a program to be execut- 
ed in a distributed manner rather than separately on a 
single CPU, short of granting a license for execution on 
all nodes of a network. 

[0054] In a large organization such as a company or 
government agency having various departments and di- 
visions, geographically dispersed, a software license 
policy is difficult to administer and enforce, and also like- 
ly to be more costly, if individual licenses are negotiated, 
granted and administered by the units of the organiza- 
tion. A preferred arrangement would be to obtain a sin- 
gle license from the software producer, and then split 
this license into locally-administered parts by delega- 
tion. The delays caused by network communication can 
thus be minimized, as well as budgetary constraints im- 
posed on the divisions or departments. Aside from this 
issue of delegation, the license management facility 
may best be operated on a network, where the licensing 
of products run on all nodes of the network may be cen- 
trally administered. A network is not necessary for use 
of the features of the invention however, since the li- 
cense management can be implemented on a single 
platform. 

[0055] Software products are increasingly fragment- 
ed into specific functions, and separate distribution of 
the functions can be unduly expensive. For example, a 
spreadsheet program may have separate modules for 
advanced color graphics, for accessing a database, for 
printing or displaying an expanded list of fonts, etc. Cus- 
tomers of the basic spreadsheet product may want 



some, none or all of these added features. Yet, it would 
be advantageous to distribute the entire combination as 
one package, then allow the customer to license the fea- 
tures separately, in various combinations, or under dif- 
5 fering terms. The customer may have an entire depart- 
ment of the company needing to use the spreadsheet 
every day, but only a few people who need to use the 
graphics a few days a month. It is advantageous, there- 
fore, to provide alternatives for varied licensing of parts 
or features of software packages, rather than a fixed pol- 
icy for the whole package. 

[0056] Another example of distribution of products in 
their entirety, but licensing in parts, would be that of de- 
livering CD ROMs to a customer containing all of the 
software that is available for a system, then licensing 
only those parts the customer needs or wishes to pay 
fees for rights to use. Of course, the product need not 
be merely applications programs, operating systems, or 
traditional executable code, but instead could also in- 
clude static objects such as printer fonts, for example, 
or graphics images, or even music or other sound ef- 
fects. 

[0057] As will be explained below, calling and caller 
authorizations are provided in the system according to 
one feature of the invention, in order to provide techno- 
logical support for a number of business practices and 
solve technical problems which require the use of what 
is called transitive licensing." By "transitive licensing" 
is meant that the right to use one product or feature im- 
plies a right to use one or more other products or fea- 
tures. Transitive licenses are similar to group licenses 
in that both types of license consist of a single instru- 
ment providing rights of use for a plurality of products. 
However, transitive licenses differ from group licenses 
in that they restrict the granted rights by specifying that 
the licensed products can only be used together and by 
further specifying one or more permitted inter-product 
calling/caller relationships. Some examples may help to 
clarify the use and nature of a transitive license: the ex- 
amples to be explained are (1 ) two products sold togeth- 
er, (2) a give-away that results from narrow choices of 
licensing alternatives, (3) a client licensing method in a 
client/server environment, (4) impact of modular design, 
and (5) the impact of distributed design. 
[0058] A software vendor m ight have two products for 
sale: the first a mail system, and the second a LEXIS™- 
like content-based text retrieval system. Each of these 
products might be valued at $500 if purchased sepa- 
rately. Some customers would be satisfied by purchas- 
ing the rights to use only one of these products, others 
might find that they can justify use of both. In order to 
increase the likelihood that customers will, in fact, pur- 
chase both products, it would not be surprising if the 
software vendor offered his potential customers a vol- 
ume discount, offering the two products for a combined 
price of $800. The customers who took advantage of 
this combined offer would find that they had received 
two products, each of which could be exploited to its full- 
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est capabilities independently from the other. Thus, 
these customers would be able to use the content based 
retrieval system to store and retrieve non-mail docu- 
ments. However, from time to time, the vendor may dis- 
cover that particularly heavy users of mail wish to be 
able to use the content based retrieval system only to 
augment the filing capabilities provided by the standard 
mail offering. It is likely that many of these potential cus- 
tomers would feel that $800 is simply too much to pay 
for an extended mail capability. The vendor might then 
consider offering these customers a license that grants 
mail users the right to use the content-based retrieval 
system only when they are using mail and prohibits the 
use of content based retrieval with any other application 
that might be available on the customers system. This 
type of license is referred to be tow a "transitive license, 
" and it might sell for $600. 

[0059] Another example is a relational database prod- 
uct (such as that referred to as Rdb™) designed for use 
on a particular operating system, e.g., VMS. This rela- 
tional database product has two components: (1 ) A user 
interface used in developing new databases, and (2) a 
"run-time - system which supports the use of previously 
developed databases. The developers of the database 
product might spend quite a bit of effort trying to get oth- 
er products made by the vendor of the database product 
to use it as a database instead of having those other 
products build their own product-specific databases. 
Unfortunately, the other product designers may com- 
plain that the cost of a run-time license for the database 
product, when added to the cost of licenses for their 
products, would inevitably make their products uncom- 
petitive. Thus, some mechanism would be needed that 
would allow one or another of the vendor's products to 
use the run-time system for the relational database 
product in a "private" manner while not giving unli- 
censed access to products of other vendors. No such 
mechanism existed, prior to this invention; thus, the ven- 
dor might be forced to sell the right to use its run-time 
system for the database product with its proprietary op- 
erating system license. Clearly, this combined license 
would make it possible for the vendor's products to use 
its database product without increasing their prices; 
however, it also would make it possible for any custom- 
ers and third-parties to use the database product without 
paying additional license fees. However, had the system 
ol the invention been available, the vendor could have 
granted transitive licenses for the run-time component 
of its database product to all the vendor's products Es- 
sentially, these licenses would have said that the data- 
base run-time could be used without an additional li- 
cense fee if and only if it was used in conjunction with 
some other of the vendor's products. Any customer 
wishing to build a new relational database application 
or use a third-party application that relied on the ven- 
dor's database product would have had to pay the ven- 
dor for rts database run-lime license. 
[0060] A proposed client/server licensing method pro- 



vides yet another example of a problem which could be 
solved by transitive licensing. Typically, a client is only 
used by one user at a time, while a server can support 
an arbitrary number of clients depending on the level of 
5 client activity and the capacity of the machine which is 
supporting the server. While traditionally, server/client 
applications have been licensed according to the 
number of clients that a server could potentially support, 
this may not be the most appropriate method for licens- 
ee ing when the alternatives afforded by the invention are 
considered. The business model for the proposed client/ 
server method requires that each client be individually 
licensed and no explicit licensing of servers is required 
to support properly licensed clients. Such a licensing 
is scheme makes it possible to charge customers only for 
the specific number of clients they purchase. Addition- 
ally, it means that a single client can make use of more 
than one server without increasing the total cost of the 
system. The solution to this transitive licensing problem 
20 would be to provide a mechanism that would allow the 
clients to obtain license unit allocations and then pass 
a ■proof of that allocation to any servers they may wish 
to use. Servers would then support any clients whose 
proofs could be verified to be valid. On the other hand, 
25 if a client that had not received a proof of allocation at- 
tempted to use a server, the server would obtain a li- 
cense allocation for that client session prior to perform- 
ing any services. Such a sol ut ton has not been hereto- 
fore available. 

30 [0061 ] As the complexity and size of the software sys- 
tems provided to customers increases, it is found that 
the actual solution provided to customers is no longer a 
single product. Rather, customers are more often now 
offered solutions which are buift up by integrating an in- 

35 creasing number of components or products, each of 
which can often stand alone or can be part of a large 
number of other solutions. In fact, a product strategy 
may rely almost exclusively on the vendor's engineering 
and selling a broad range of specialized components 

40 that can only be fully exploited when combined together 
with other components into a larger system. Such com- 
ponents include the relational database runtime system 
mentioned above, mail transport mechanisms, hyperin- 
formation databases, document format conversion 

45 services, time services, etc. Because these compo- 
nents are not sold on their own merits, but rather on their 
ability to contribute to some larger system, it is unlikely 
that any one customer will be receiving the full abstract 
economic value of any one of the components once in- 

50 teg rated into a system. Similarly, it can be observed that 
the value of any component once integrated into a larger 
system varies greatly from system to system. Thus, it 
may be found that a mail transport mechanism contrib- 
utes a large part of a system whose primary focus is 

55 mail, however, it will contribute proportionally less of the 
value of a system that provides a broader office auto- 
mation capability. As a result of these observations, the 
job of the business analyst who is attempting to find the 
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"correct" market price for each component standing on 
its own, is more complex. In reality, the price or value of 
the component can only be determined when consider- 
ing the contribution of that component to the full system 
or solution in which it is integrated. Attempting to sell the s 
components at prices based on their abstract, inde- 
pendent values will simply result in overpriced systems. 
[0062] Transitive license styles are particularly suited 
to dealing with pricing of modular components, since 
component prices can be clearly defined in relation to 10 
the other components or systems which they support. 
Thus, a vendor can charge a price of $100 for the right 
to use a mail transport system in conjunction with one 
product, yet charge $200 for the use of the same mail 
transport system when used by another product. is 
[0063] In addition to the "business" reasons for want- 
ing to support transitive licensing, there is also a very 
good technical reason that arises from the growing ten- 
dency of developers to build "distributed products" as 
well as the drive toward application designs that exploit 20 
either tightly or loosely coupled multiprocessor systems; 
the availability and growing use of remote procedure 
calls has contributed to this tendency. This technical 
problem can be seen to arise when considering a prod- 
uct which has a number of components, each of which 
may run in a different process space and potentially on 
a different computer system. Thus, there might be a mail 
system whose user interface runs on one machine, its 
"file cabinet" is supported by a second machine and its 
mail transport system runs on yet a third machine. The 30 
simple question which arises is: "Which of the three 
components should check for licenses?" Clearly it must 
be ensured that no single component can be used if a 
valid license is not present. Thus, the answer to the 
question will probably be that all three components 35 
should check for licenses. However, the question is then 
presented: "Where are the licenses to be located?-. This 
can become more complex. 

[0064] Increasingly, the distributed systems being 
built are being designed so that it is difficult to predict 40 
on which precise machine any particular component will 
run. Ideally, networks are supposed to optimize the 
placement of functions automatically so that the ma- 
chine with the most available resource is always the one 
that services any particular request. This dynamic meth- 45 
od of configuring the distribution of function servers on 
the network makes it very difficult for a system or net- 
work manager to predict which machines will run any 
particular function and thus very difficult for him to de- 
cide on which machines software licenses should be 50 
loaded. 

[0065] Even if a system manager could predict which 
machines would be running the various application com- 
ponents and thus where the license units should be 
loaded, the situation would still be less than ideal. The 55 
problem arises Irom the fact that each of the compo- 
nents ol the application would be independently making 
requests for license unit allocations. This behavior will 



result in a difficult problem for anyone trying to decide 
how many license units are required to support any one 
product. Given the mail example, the problem wouldnl 
exist if it were assumed that all three components (i.e., 
user interface, file cabinet, and transport system) were 
required by the design of the mail system to be in use 
simultaneously. If this were the case, it could be simply 
assumed that supporting a single activation of the mail 
system would require three units. However, in a real mail 
system, it will be inevitably discovered that many users 
will only be using just the user-interface and file-cabinet 
components of the system at one time. Thus, there will 
be some unused units available which could be used to 
authorize additional users. This situation might not be 
what is desired by the software vendor. 
[0066] The problem of providing license support to 
multi-component product which are dynamically config- 
ured could be solved by viewing each of the product 
components as a distinct licensable product and by 
treating the problem as one of transitive licensing, but a 
mechanism for accomplishing this has not been availa- 
ble. Essentially, a single license document would be cre- 
ated that stated that if any one of the components had 
successfully obtained a license to run, it could use this 
grant to give it the right to exploit the other components. 
Thus, in the example above, the user might start the mail 
system by invoking its user interface. This user interface 
code would then query the license management facility 
for a license allocation and once it has received that al- 
location, it would pass a proof of allocation to the other 
mail components that it uses. Each of the other compo- 
nents would request that the license management sys- 
tem validate that the "proof is valid prior to performing 
any service; however, none of the other components 
would actually require specific allocations to be made to 
them. In this way, the complexity of licensing and man- 
aging networks of distributed applications can be signif- 
icantly reduced. 

[0067] In accordance with one embodiment of the in- 
vention, a license management system is used to ac- 
count for software product usage in a computer system. 
The system employs a license management method 
which establishes a management policy having a variety 
of simultaneously-available alternative styles and con- 
texts. A license server administers the license, and each 
licensed product upon start-up makes a call to the li- 
cense server to check on whether usage is permitted, 
in a manner similar to that of patent 4,937,863. The li- 
cense server maintains a store of the licenses, called 
product use authorizations, that it administers. Upon re- 
ceiving a call from a user, the license server checks the 
product use authorization to determine if the particular 
use requested is permitted, and, if so, returns a grant to 
the requesting user node. The license server maintains 
a database of product use authorizations lor the li- 
censed products, and accesses this database for updat 
ing and when a request is received Irom a user. While 
this license management system is perhaps of most util- 
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ity on a distributed computer system using a local area 
network, it is also operable in a stand-alone or cluster 
type of system. In a distributed system, a license server 
executes on a server node and the products for which 
licenses are administered are on client nodes. However, 
the license management functions and the licensed 
products may be executing on the same processor in 
some embodiments. 

[0068] The product use authorization is structured to 
define a license management policy allowing a variety 
of license alternatives by components called "style", 
"context", "duration" and "usage requirements determi- 
nation method'. The style may be al locative or con- 
sumptive. An af locative style means the units of the li- 
cense may be allocated temporarily to a user when a 
request is received, then returned to the pool when the 
user is finished, so the units may be reused when an- 
other user makes a request. A consumptive style means 
the units are deducted from an available pool when a 
user node makes a valid request, and "consumed", not 
to be returned for reuse. The context value defines the 
context in which the use is to be allowed, such as on a 
particular network, by a particular type of CPU, by a par- 
ticular user name, by a particular process, etc. The du- 
ration value (used in conjunction with the style compo- 
nent) concerns the time when the license units are to be 
deducted from the available pool of units, whether at the 
time of request, after a use is completed, etc. A usage 
requirements determination method may be specified to 
define or provide information concerning the number of 
license units charged in response to a license request 
from a user node; for example, some CPU platforms 
may be charged a larger number of license units than 
others. A table may be maintained of usage require- 
ments, and the determination method may specify how 
to access the table, for example. The important point is 
that the user node (thus the software product) can only 
make a request, identifying itself by user, platform, proc- 
ess, etc. , and the license management facility calculates 
whether or not the license can be granted (that is, units 
are available for allocation), without the user node hav- 
ing access to any of the license data or calculation. 
There is a central facility the license server, storing the 
license documents, and, upon request, telling the li- 
censed products whether they can operate under the 
license terms. 

[0069] An important feature of one embodiment is that 
the license administration may be delegated to a sub- 
section of the organization, by creating another license 
management facility duplicating the main facility. For ex- 
ample, some of the units granted in the product use au- 
thorization may be delegated to another server, where 
the user nodes serviced by this server make requests 
and receive grants 

[0070] The license management facility cannot create 
a license itself, but instead must receive a license doc- 
ument (a product use authorization) from an issuer of 
licenses. As part of the overall license management sys- 



tem of the invention, a license document generator is 
provided which creates the product use authorizations 
under authority of the owner of the software, as negoti- 
ated with customers. Thus, there are three distinct rights 

s in the overall license management facility of the inven- 
tion: (1) the right to issue licenses, (2) the right to man- 
age licenses, and (3) the right to use the licensed prod- 
ucts. Each one of these uses the license document only 
in prescribed ways. The license issuer can generate a 

fo license document. The license manager (or license 
server as referred to herein) can grant products the right 
to use under the license, and can delegate parts of the 
licensed units for management by another server, as de- 
fined by the license document; the way of granting rights 

is to products is by responding to certain defined calls from 
the products. And, the licensed products can make cer- 
tain calls to the license server to obtain grants of rights 
based upon the license document, inquire, or report, but 
ordinarily cannot access the document itself. 

20 [0071] As explained above, transitive licensing is an 
important feature of one embodiment. This is the provi- 
sion of a mechanism for one user node to get permission 
to use another software product located on another user 
node; this is referred to as a calling authorization and a 

25 caller authorization, using a "calling card," and these are 
examples of the optional features which must be specif- 
ically permitted by the product use authorization. A user 
node must obtain permission to make a procedure call 
to use a program on another node; this permission is r 

30 obtained by a request to the license server as before, 
and the permission takes the form of a calling card. 
When a calling card is received by a second node (i.e., 
when the procedure call is made), a request is made by 
the second node to the license server to verify (via the 

35 product use authorization) that the calling card is valid, 
and a grant sent to the user node if allowed. In this man- 
ner, all nodes may have use of a program by remote 
calls, but only one consumes license units. 
[0072] Another important feature of one embodiment 

40 js a management interface which allows a license man- 
ager to modify the license policy components of a li- 
cense document maintained by at a license server in its 
database. Usually the license manager can only make 
modifications that restrict the license policy components 

^5 to be more restrictive than originally granted. Of course, 
the management interface is used to make delegations 
and assignments, if these are authorized. 
[0073] The license document interchange format is an 
important feature, in that it allows the license manage- 

50 ment system to be used with a wide variety of software 
products from different vendors, so long as all follow the 
defined format The format uses data structures that are 
defined by international standards 
[0074] An important function is the filter function, used 

55 jn the management interface and also in the client inter- 
face to select among elements in the data structures 
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BRIEF DESCRIPTION OF THE DRAWINGS 

[0075] The novel features believed characteristic of 
the invention are set forth in the appended claims. The 
invention itself, however, as well as other features and $ 
advantages thereof, will be best understood by refer- 
ence to the detailed description of specific embodiments 
which follows, when read in conjunction with the accom- 
panying drawings, wherein: 

10 

Figure 1 is a diagram in block form of a distributed 
computer system which may be used to implement 
the license management operations according to 
one embodiment of the invention; 

15 

Figure 2 is a diagram of the content of a license doc- 
ument or "product use authorization" generated by 
the license document generator and stored by the 
license server in the system of Figure 1 ; 

20 

Figure 3 is a diagram of the alternatives for license 
style, context and duration making up the license 
management policy implemented in the system of 
Figure 1 , according to one embodiment of the in- 
vention; 25 

Figure 4 is a diagram of an example of a fragment 
of a license use requirements table (LUFTT) used in 
the system of Figure 1 , according to one embodi- 
ment of the invention; 30 

Figure 5 is a logic flow chart of a program executed 
by a user node (client), in the system of Figure 1 , 
according to one embodiment of the invention; 

35 

Figure 6 is a logic flow chart of a program executed 
by a license server, in the system of Figure 1 , ac- 
cording to one embodiment of the invention; and 

Figure 7 is a diagram of the calls and returns made 40 
in an example of use of calling cards in the system 
of Figure 1. 

Figure 8 is a diagram of an LDIF document identifi- 
er, according to an standard format; 45 

Figure 9 is a syntax diagram of an LDIF document; 

Figure 10 is a diagram of an LDIF document struc- 
ture; 50 

Figures 11, 13, 15, 17, 18, 19, 21-28 and 31 -43 are 
syntax diagrams for elements of various ones of the 
LDIF data structures; 

55 

Figure 16 is a diagram of a license data structure; 
Figures 1 2, 1 4 and 20 are examples of descriptions 
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of data elements using a standard notation; 

Figures 29 and 30 are examples of context tem- 
plates used in the license management system; 

Figures 44 and 45 are tables of attributes specific 
to filter and filter item type; and 

Figure 46 is notation in a standard format for an ex- 
ample of a filter. 

DETAILED DESCRIPTION OF SPECIFIC 
EMBODIMENTS 

[0076] Referring to Figure 1 , a license mana gement 
fa cility acc ordin g to one example embodiment of the in- 
vention is centered around a license server 10, which 
typically includes a CPU located in the customer's main 
office and executing a license management program 11 
as will be described, under an operating system 1 2. The 
license server 10 communicates with a number of del- 
egatees 1 3 which likewise include CPUs in departments 
or divisions of the company or organization, each also 
executing a license management program 1 4 under an 
operating system 1 5. The license management program 
1 4 is the same as the program 1 1 executing on the main 
server 10; the only difference in the functions of server 
10 and servers 13 is that the latter have a delegated 
subset of the license units granted to the server 10, as 
will be described. The CPUs 13 are in turn servers for 
a number of users 16, which are CPU nodes where the 
licensed programs 17 are actually executed. The pro- 
grams 1 7 executing on the user CPUs 1 6 are applica- 
tions programs (or operating systems, etc.) which have 
added to them units 18 and 19, according to the inven- 
tion, allowing them to make inquiry to the their server 1 3 
(or 10) before executing and to report back after execut- 
ing, using a client stub 19 in the manner of remote pro- 
cedure calls, in one embodiment. A user node 16 may 
have many different programs 17 that may be executed, 
and the various user nodes 16 would usually each have 
a set of programs 1 7 different from the other user nodes, 
all of which would be administered by the license man- 
agement program 14 or 11. The terms "program" and 
"licensed product" are used in reference to the element 
17, but it is understood that the products being admin- 
istered may be segments of programs, or functions or 
features called by another program, or even merely data 
(such as printer fonts), as well as complete stand-alone 
applications programs. The license server 10 commu- 
nicates with the delegatee servers 1 3 by a network 21 , 
as is usual in large organizations, and the delegatee 
servers 13 each communicate with their user nodes 16 
by networks 22; these networks may be of the Ethernet, 
token ring, FDDI types or the like, or alternatively, the 
user nodes 16 may be merely a cluster of terminals on 
a multiuser system with the delegatee being a host CPU . 
The particular hardware construction of the user nodes, 
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server nodes, communication networks, etc., and the 
operating systems 12 or 15, are of no concern regarding 
the utility of the features of the invention, the only im- 
portant point being that the user CPUs 1 6 of the software 
products 17 in question can communicate readily and 
quickly with their respective server nodes 13 or 10. In 
one embodiment, remote procedure calls (RPCs) are 
used as the communication medium for the interfaces 
between components of the system, handling the inquir- 
ies and grants as will be described. A remote procedure 
call is similar to a local procedure call but is made to a 
procedure located on a remote node, by way of a com- 
munications network. 

[0077] The function of the unit 19 is that of a client 
stub, in a remote procedure call sense. The calls to the 
license server 10 are made through this stub 19, and 
returns are received by the stub 1 9 and passed on to 
the program 1 7. The stub 1 9 is responsible for obtaining 
the network addresses of other nodes on the network, 
such as the server 10. Also, the stub 19 is responsible 
for determining the context (as defined below) for pass- 
ing on to the server 10. The unit 18 functions to execute 
a "private" type of license availability determination if 
this is used, rather than this task being done by the ap- 
plication program 17, but if the ordinary method of de- 
termination is employed (using the license server) as is 
usually the case, the unit 18 is merely code that starts 
the execution and passes calls and returns back and 
forth between the program 17 and the unit 19. 
[0078] The license server 10, using the license man- 
agement program 11, maintains a license data file 23 
comprising a number of license documents or licenses 
(product use authorizations), and also maintains a log 
24 which is a record of the usage activity of all of the 
user CPUs 16 of each of the licensed programs. The 
delegatee servers 1 3 would maintain similar license da- 
tabases and logs. The license server 1 0 has no authority 
to originate a license, but instead must receive a license 
from a license issuer 25. The issuer 25 is again a CPU 
executing a license document generator program 26 un- 
der an operating system 27. The license issuer 25 may 
be under control of the producer 28 of the programs or 
software products being licensed, or may be controlled 
by a distributor who has received the authority to grant 
licenses from the producer or owner 28. 
[0079] This mechanism permits the system of the in- 
vention to dispose of the cumbersome, explicit support 
of license types having different scope such as the clus- 
ter licenses, node licenses, and process licenses found 
in prior license management systems including that of 
patent 4,937,863. Instead of defining a limited set of 
scopes (cluster, node, etc.), the system of this invention 
provides a general mechanism which allows an effec- 
tively unlimited range of allocation scopes to be defined. 
[0080] Transitive licensing, as referred to above, is 
supported by the system of the invention by (1) calling 
authorizations, which are statements made in field 49 of 
the product use authorization 35 for one product (the 



"caller") to permit that product to call another product 
(the "callee"), and, (2) caller authorizations, which are 
statements made in field 49 of the product use authori- 
zation for one product (the "callee") to permit it to be 
5 called by another product (the "caller"). 

[0081] If calling or caller authorizations are to be ex- 
ploited by products, then whenever one product calls 
another product, it must pass the callee a calling card 
49a. This calling card 49a is an encoding of an identifi- 

10 cation of the caller as wel I as a statement by the license 
management system that a license unit allocation has 
been made to the caller which is passing the calling 
card. This calling card is then passed by the callee to 
the license management system for validation and, if the 

15 either the product use authorization of the caller carries 
an appropriate calling authorization or the product use 
authorization of the callee carries an appropriate caller 
authorization, the use of the callee by the caller will be 
authorized without requiring any additional license unit 

20 allocations. 

[0082] Referring to Figure 7, the intercomponent in- 
teractions that occur when either calling or caller author- 
izations are being used are illustrated. This figure shows 
a license management server 10, a caller product 17a 

25 named "Product-1" and a callee product 17b named 
"Product-2". When Product-1 starts to run, it will make 
an fm_request_atlocation() call to the license manage- 
ment server 1 0 to obtain a grant handle for an allocation 
of some number of units of the Product-1 license. Either 

30 immediately, or at some later time, but always prior to 
making a call to Product-2, Product-1 will call 
lm_query_aflocation(), passing the grant handle re- 
ceived earlier and specifying that it wants a calling card 
for the product named "Product-2." If the field 49 of the 

35 product use authorization 35 used to satisfy the grant 
represented by the grant handle carries a calling author- 
ization in field 49 naming "Product-2, " the license man- 
ager will create a calling card 49a which includes the 
statement that a calling authorization exists and pass 

40 this calling card back to Product-1 . If the calling author- 
ization does not exist, the calling card passed to Prod- 
uct-1 will contain a statement to that effect. 
[0083] Once Product-1 has successfully obtained a 
calling card 49a from the license manager, it will then 

45 make a call to Product-2, passing the calling card along 
with any other initialization parameters that would nor- 
mally be used when starting Product-2. Product-2 will 
then pass that calling card to the license manager as 
part of its lm_request__allocatton() call and the license 

50 manager will determine if the calling card is valid. Note 
that calling cards become invalid once the process 
which received the calling card makes an 
lm_release_allocation() call or terminates abnormally If 
the calling card is valid, and it indicates that a calling 

55 authorization is present, the license manager will verify 
this statement and if found to be true, will return a grant 
handle to Product-2 If, on the other hand, the calling 
card carries an indication that no calling authorization is 
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present, the license manager will attempt to find a prod- 
uct use authorization for Product-2 that contains a caller 
authorization naming Product-1 as an authorized caller. 
If the caller authorization is found, a grant handle will be 
passed back to Product-2. If not, the license manager s 
will ignore the calling card and proceed with the normal 
lm_request_at!ocation() logic. 

[0084] The requirement to be passing calling cards 
between products requires that both the caller and the 
callee be "aware" of the fact that calling and caller au- io 
thorizations may be used. This is one of the few exam- 
ples of a requirement for a product 1 7 to become actively 
involved in the licensing problem when using the licens- 
ing management system of the invention. However, 
since the use of calling/caller authorizations if a fairly is 
"sophisticated" and powerful feature, it is considered ac- 
ceptable to impose this burden on application coders. 

MANAGEMENT INTERFACE 

20 

[0085] Referring to Figure 1 , the license management * 
program 11 executing on a server 10 includes a license 
management interface 33 which functions to allow a us- 
er at a console for the server 10 CPU or at a remote 
terminal to implement certain necessary operations. 25 
The management interface 33 is essentially the tools or j 
mechanisms available to the license manager at the li- \ 
censee's site to (a) load the various licenses received 
from issuers 25 into the database 23 and make them 
available for request allocation calls from the users, (b) 30 
remove the licenses from the machine when expired, (c) f 
to make delegations if permitted, (d) to make assign- ; 
ments, (e) to make reservations, etc. Whatever the li- 
cense manager is allowed to do to modify the license ; 
for his special circumstances (usually within the original .'35 
grant), he does it by the mechanism of the management j 
interface 33. Some licenses are not modified at all, but / 
merely loaded. In a multiple machine environment, as / 
on a network, there is considerable modification, as it is j 
necessary to make sure the correct number of units are j 40 
distributed onto the correct machines, the right people! 
have access, other people don't have access, etc. Thus,[ 
in a network environment, there is extensive use of the 1 
management interface 33. 

[0086] I n reference to the terminology used in describ- ^5 
ing the management interface, as well as the license 
management system in general, it is helpful to note that 
the documentation conventions, data declarations, 
macro declarations, etc., for the object management 
used in one embodiment of the invention are according so 
to the standards set forth in OS/ Object Management 
API Specification, Version 2.0, X.400 API Association 
and X/Open Company Limited, 24 August 1 990, a pub- 
lished document. 

[0087] The specific operations available to the man- 55 
agement interface 33 are to allow a manager to open 
and close a management session, register (load) ob- 
jects in the license database 23, obtain a list of objects 



in the license database 23, and control a cursor (a cursor 
is a movable pointer to a member of a list of items). Once 
an object in the license database 23 is identified with the 
cursor, certain changes may be made in the object by a 
write function. For example, certain fields of a license 
document of Figure 2 or an LURT of Figure 4 may be 
changed in only specified ways as will be explained. 
[0088] The operation of opening a session goes by 
the name of lmjopen_session() and is used to establish 
a license management service session between a man- 
agement client and the service. Opening a session also 
creates a workspace to contain objects returned as a 
result of functions invoked within the session. Object 
management Objects can be created and manipulated 
within this workspace. Objects created within this work- 
space, and only such objects, may be used as Object 
arguments to the other license management service 
management functions used during the session estab- 
lished by a call to this function. More than one session 
may exist simultaneously. 

[0089] The arguments that go with a 
fm_open_session() call are (a) the binding handle, 
which is binding information that defines one possible 
binding (a client-server relationship), and (b) a comment 
which will be inserted in the log file 24 if logging is ena- 
bled. The results from a lm_ppen_session( ) call are (a) 
a return code indicating whether the function succeed- 
ed, and, if not, why not, (b) a session, which is an es- 
tablished license management session between the 
management client and the license management serv- 
ice, and (c) a workspace that will contain all objects re- 
turned as a result of functions invoked in the session. 
[0090] The close session call is referred to by 
fm_close__session() and functions to terminate the !m 
session. This function terminates the license service 
management session and makes the argument unavail- 
able for use with other interface functions. The argu- 
ments that go with a lmjclose_session() call are (a) the 
session which identifies the established Im session be- 
tween the management client and the license manage- 
ment service, and (b) a comment which will be inserted 
in the log file if logging is enabled. The result of the call 
is a return code indicating whether the function succeed- 
ed, and, if not, why not. 

[0091] The list function returns a set of selected ob- 
jects in the license database 23, and uses the name 
lm_Hst_itcenses(). This function is used to search the 
license database 23 and return a cursor which repre- 
sents the first of one or more objects which match the 
specified filter. The specified filter will be applied to each 
object in the license database 23; all objects for which 
the filter evaluates true will be included in the object list 
accessible by the set_cursor function The arguments 
that go with ImJistJicensesQ are (a) session which 
identifies an established session between the manage- 
ment client and the license management service, and 
(b) a filter which is an object used to select license da- 
tabase 23 objects; license database objects will only be 



17 



33 



EP 0 538 453 B1 



34 



included in the object list headed by the cursor if they 
satisfy the filter - the constant no-filter may be used as 
the value of this argument if all license data objects are 
to be included in the object list. The results of the 
ImJistJicensesQ call are (a) a return code indicating 
whether the function succeeded, and, if not, why not, 
and (b) a license list upon successful completion of this 
call containing a cursor which represents the first of one 
or more objects in the current license database 23 for 
which the specified filter evaluates true. 
[0092] The register function is to register objects in 
the license database 23, and uses the name lm_jegister 
(). This function is used to register (i.e., load or create) 
new objects, or modify existing objects, in the license 
database 23; the objects which may be registered in- 
clude only those which are subclasses of the license da- 
ta class or history objects. The arguments are (a) ses- 
sion, which identifies an established session between 
the management client and the license management 
service, (b) license data object which is to be registered; 
if this argument is omitted, the comment argument is a 
required argument and a history object containing the 
comment will be registered in the license database 23, 
and (c) comment, which will be inserted in the log file ff 
logging is enabled. The result is a return code indicating 
whether the function succeeded, and, if not, why not. 
The errors possible when it does not succeed include 
data-expired, duplicate-object, no-such-session, mem- 
ory-insufficient, network-error, etc., indicated by this re- 
turn code. 

[0093] The set cursor function establishes a new cur- 
sor, and is called by lm_set_cursor(). The arguments are 
(a) session, which identifies an established session be- 
tween the management client and the license manage- 
ment service, (b) forward, which is a boolean value in- 
dicating if the direction in which the cursor is to be moved 
is forward or reverse, (c) filter which is used to eliminate 
cursors from the search for the next cursor that are not 
wanted; a new cursor will only be set if it satisfies the 
filter - the constant no-filter may be used as the value of 
this argument if any cursor is to be considered as the 
target cursor, and (d) the cursor which is to be used as 
the starting point in searching for the new cursor. The 
results are (a) a return code indicating whether the func- 
tion succeeded, and, if not, why not, and (b) next-cursor, 
which is the requested cursor. The error codes in the 
return code may be end-of-list, not-a-cursor, etc. 
[0094] After a session is opened, and an object such 
as a product use authorization or a LURT has been iden- 
tified by the cursor, using the functions explained above, 
the management interface 33 is able to execute certain 
object management interface functions such as write or 
copy. By this mechanism, the management interface 
can modify certain limited attributes. Usually, none of 
these attributes can be modified in such a way that they 
reduce constraints established by corresponding at- 
tributes in the license data objects. The more important 
attributes which can be modified by the management 



interface 33 using this mechanism are: 

(a) assignment: an assignment of some or all of the 
units granted on the associated product use author- 

5 ization; 

(b) reservation: a reservation of some or all of the 
units granted on the associated product use author- 
ization; 

(c) delegation: a delegation of the right to manage 
io some or all of the units granted on the associated 

product use authorization, or if the associated li- 
cense data is not a product use authorization, the 
delegation is of the right to use that license data; 

(d) backup delegation: a statement of the right to 
15 manage some or all or the units granted on the as- 
sociated product use authorization; this right is only 
active at times when the delegating server is not 
available; 

(e) allocation: an allocation of units to a specific con- 
20 text; 

(f) allocation period: the minimum duration of a sin- 
gle allocation - all allocated units cannot be allocat- 
ed to a new context until a time period equal to the 
allocation period has passed since the units were 

25 last allocated; 

(g) termination date: a date which is to override the 
value specified as the end date of the product use 
authorization 40 - this date must be earlier than 
specified; 

30 (h) delegation permitted: an override of the delega- 
tion permitted flag of the associated license data; 
(i) overdraft: the current overdraft level; 
(j) overdraft logging: an override of the overdraft log- 
ging attribute of the associated product use author™ 

35 ization; 

(k) comment: a comment created by the licensee; 
(I) extended info: information not defined by the ar- 
chitecture which may be of use in managing the li- 
cense data. 

40 

It will be noted that an assignment and a reservation are 
identical, the only difference being that a reservation is 
something optional, while an assignment is something 
that is required. If the duration is Assignment in the pol- 

45 icy declaration of Figure 3, the license manager must 
assign some or all of the units before units can be allo- 
cated. Reservations, on the other hand, are made by 
the license manager using the management interface, 
regardless of the policy. 

50 [0095] Thus, there are certain attributes that can be 
changed by license administrator using the manage- 
ment interface at the server 1 0, but usually none of these 
can result in obtaining more extensive rights to use than 
granted by the product use authorization. In each case, 

55 the license administrator can limit the rights which will 
be allocated to users in some way that may be appro- 
priate for the administrator for control purposes 
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LICENSE DOCUMENT INTERCHANGE FORMAT 

[0096] The major structural components of an ASN.1 
encoded document which conforms to the specifications 
for the license management system discussed above 
will be described. The object identifier that is assigned 
to this data syntax, according to one embodiment, is that 
specified in ASN. 1 as seen in Figure 8. The International 
Standards Organization or ISO, as it is referred to, de- 
fines how bit patterns are chosen to uniquely identify an 
object type, so the bit pattern set forth in Figure 8 would 
preceed each document used in the license manage- 
ment system so the document could be identified as be- 
ing a document conforming to the prescribed License 
Document Interchange Format. 
[0097] A document encoded according to this format 
is represented by a value of a complex data type called 
"license document interchange format document" of LD- 
IFDocument, in this embodiment. A value of this data 
type represents a single document. This self -describing 
data structure is of the syntax defined in the international 
standard ASN.t referred to above. The X/Open stand- 
ard referred to above defines the conventions that must 
be used in employing this syntax, while the syntax itself 
is described in an OSI (Open Systems Interconnect, a 
standard administered by ISO) document identified as 
X-409 (referenced in the X/Open document identified 
herein). 

[0098] The LDIFDocument data type consists of an 
ordered sequence of three elements: the document de- 
scriptor, the document header, and the document itself. 
Each of these elements are in turn composed of other 
elements. The overall structure of the LDIFDocument 
data type will be described, and the nature of the docu- 
ment descriptor and document header types. Then, the 
document content elements will be described in detail, 
as well as the various component data types used in the 
definition of the descriptor, the header and the content. 
[0099] The LDIFDocument represents a single li- 
cense document, with the syntax being shown in Figure 
9 and the high-level structure of an LDIF document in 
graphical form being seen in Figure 10. The Document- 
Descriptor of Figure 9 is a description of the document 
encoding, the DocumentHeader contains parameters 
and processing instructions that apply to the document 
as a whole, and the DocumentContent is the content of 
the document, all as explained below. 
[0100] Referring to Figure 9, what this says is that an 
LDIFDocument is composed of (::- means "is com- 
posed of) a number of elements, the first thing in an 
LDIFDocument is a bit pattern (tag) according to an in- 
ternational standard, indicating a certain type of docu- 
ment follows, which is indicated here to be "private" or 
vendor selected, the number 1 6373 in this case Follow- 
ing the bit pattern which functions as a "starting delim- 
iter" it is "implicit" that a "sequence" of elements must 
follow, where a sequence is distinguished from a set. A 
sequence is one or more of the elements to follow, 



whereas a set is exactly one of the elements to be listed. 
Implicit means that any file identified as LDIFDocument 
must have a sequence data type, rather than some other 
type. In the case of Figure 9, the sequence is document- 
s descriptor, document header and document content; the 
document-content is mandatory, whereas the first two 
are optional. If an element in the sequence begins with 
a "0" it is a document-descriptor, "1 " means a document- 
header, and "2" means it is a document-content. Again, 

10 ft is implicit that the data following is of the format Doc- 
umentDescriptor, etc., in each case, and these are de- 
fined in Figure 11, Figure 13 and Figure 15. 
[01 01 ] Each file is in the tag-length-value format-men- 
tioned above, and also each element of a file containing 

is multiple elements is of the tag-length-value format. The 
data stream could be examined beginning at any point, 
and its content determined by first looking for a tag, 
which will tell what data structure this is, then a length 
field will say how long it is, then the content will appear. 

20 These structures are nested within one another; a doc- 
ument containing several product-use-authorizations 
would be an LDIFDocument of the format of Figure 9, 
with a number of DocumentContent elements of Figure 
15 following, with the length given for the LDIFDocu- 

25 ment spanning the several PUAs, and the length given 
for each PUA being for the one PUA. 
[0102] In Figure 11, the elements major-version and 
minor-version are seen to be "implicit integer". This 
means that because the element is of the type major- 

30 version, etc.. it must be an integer, various other implicit 
types are given in other syntax diagrams, such as char- 
acter-string, boolean, etc. 

[0103] In Figure 15, the license body is identified as 
being of the type "choice" meaning it can be one of PUA, 

35 LURT, GroupDefinition, KeyRegistration, etc. Thus, 
knowing this is a license-body does hot mean the data 
type of the object* isknown; it is a bit further where the 
kind of a license-body becomes known. The defintion of 
a license body is not implicit, but instead is a chioce type. 

40 [01 04] The contents of the various data elements will 
now be described in detail with reference to Figures 
11-43. Using these detailed descriptions, the exact for- 
mat of each of the elements used in the LDIF can be 
interpreted. 

45 [0105] The license document descriptor or Docu- 
mentDescriptor consists of an ordered sequence of four 
elements which specify the version level of the LDIF en- 
coding and identify the software that encoded the doc- 
ument, with the syntax being shown in Figure 11 . An ex- 

50 ample of the way a product called PAKGEN V1 .0 is ex- 
pressed in the Document Descriptor encoding is shown 
in Figure 12. The fields in the DocumentDescriptor syn- 
tax are major-version, minor-version, encoder-identifier 
and encoder-name. The major-version field is the pri- 

55 mary indicator of compatibility between LDIF proces- 
sors and the encoding of the present document; this ma- 
jor-version field is updated if changes are made to the 
system encoding that are not backward compatible. The 
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minor-version field is the revision number of the system 
encoding. The encoder-identifier field is a registered fa- 
cility mnemonic representing the software that encoded 
the document; the encoder-identifier can be an acronym 
or abbreviation for the encoder name - this identifier is 5 
constant across versions of the encoder. The encoder- 
identifier should be used as a prefix to Named Value 
Tags in Named Value Lists to identify the encoder of the 
named value. The encoder-name field is the name of 
the product that encoded the document; the encoder- 10 
name string must contain the version number of the 
product. 

[0106] The document header or DocumentHeader 
contains data that pertains to the document as a whole, 
describing the document to processors that receive it; is 
the syntax is shown in Figure 13. An example of a doc- 
ument header is shown in Figure 14, using the hypothet- 
ical product PAKGEN V1.0 of Figure 12 The private- 
header-data contains the global information about the 
document that is not currently standardized; all interpre- 20 
tations of this information are subject only to private 
agreements between parties concerned, so a processor 
which does not understand private header data may ig- 
nore that data. The Title field is the user-visible name of 
the document. The Author field is the name of the person 25 
or persons responsible for the information content of the 
document. The Version field is the character string used 
to distinguish this version of the document from all other 
versions. The Date filed is the date associated with this 
document. Note that the nature and significance of the 30 
Title, Author, Version, and Date fields can vary between 
processing systems. 

[01 07] The content of an LDI F document is represent- 
ed by a value of a complex data type called Document- 
Content. An element of this type contains one or more 3S 
LicenseData content element using a syntax as shown 
in Figure 15. There are no restrictions on the number, 
ordering or context of LicenseData elements. The struc- 
ture of a LicenseData element is represented in Figure 

16. No restrictions are made on the number, ordering, 40 
or context of LicenseData elements. The license-data- 
header field of Figure 16 specifies that data, common to 

all types of license data, which describes the parties to 
the licensing agreement, the term of the agreement, and 
any constraints that may have been placed on the man- 45 
agement of the license data encoded in the license 
body. The license-body is an element that contains one 
content element, including; product use authorizations, 
license unit requirements tables, group definitions, key 
registrations, and various forms of delegations. The 50 
Management-Info is an element that contains informa- 
tion concerning the current state of the license data; this 
element is not encoded by Issuers. 
[0108] The license data header, called LicenseData- 
Header, is represented as a syntax diagram in Figure £5 

17. The license-id field provides a potentially unique 
identification of the encoded license d ata, so issuers of 
license data can generate unique license-ids to distin- 



g uish each issuance of license da ta; however, the ar- 
chitecture does not require this to be the case, since the 
only architectural restriction is that no two objects in any 
single license management domain may have the same 
value for license-id. The licensee field identifies the par- 
ty who has received the rights reflected in the license 
data; there are at least two parties involved in all trans- 
fers of license data, first, the issuer of the license data, 
and second, the licensee or recipient of that data - it is 
anticipated that individual licensees will specify to those 
issuing them licenses what the licensee fields on their 
license data should contain, the term field identifies the 
term during which the license data may be used; the va- 
lidity of license data can be limited by issuers to specific 
time ranges with given starting and ending dates, which 
are carried in the term element - attempts to use license 
data or products described by that data either before the 
start date or after the end date will result in conforming 
license managers denying access to the license. Man- 
agement-constraints identifies constraints placed on the 
right to manage the associated license data; these con- 
straints can include (a) limiting the set of contexts per- 
mitted to manage the data, (b) limiting the set of plat- 
forms which may benefit from that management, and (c) 
limiting the right to backup and delegate the managed 
data. The signature provides the digital signature used 
by the issuer to sign the license data and identifies the 
algorithm used in encoding the signature. Issuer-com- 
ment is a comment provided by the issuer and associ- 
ated with the license data. 

[01 09] The IssuerComment is of an informational na- 
ture and does not impact the process of authorizing 
product or feature use. This field is not included in the 
fields used to generate the signature for a license, thus, 
even if specified by an issuer, the IssuerComment can 
be omitted from a license without invalidating the li- 
cense. If specified, the IssuerComment should be 
stored in the appropriate license data base with the as- 
sociated license data. The IssuerComment can be re- 
trieved by products which use the system and may be 
of particular utility to products in the "Software Asset 
Management" domain which are intended to extend or 
augment the administrative or accounting facilities or 
basic system components. Some examples of potential 
uses for this field are order information, additional terms 
and conditions, and support information. For order in- 
formation, some issuers may wish to include with their 
loadable license data some indication of the purchase 
order or orders which caused the license data to be is- 
sued; licensees may find it useful to include this data in 
their license databases to assist in the license manage- 
ment process. For additional terms and conditions, the 
system will never provide automatic means for the man- 
agement of all possible license terms and conditions, 
and so some issuers may wish to include summaries of 
non-system managed terms and conditions in the com- 
ment as a reminder. For support information, the Issu- 
erComment could be used to record the phone numbers 
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or addresses of the responsible individuals within the 
issuing organization who should be contacted if there 
are problems with the data as issued. 
[0110] A product use authorization as previously dis- 
cussed in reference to Figure 2 is used to express the s 
issuance of a right to use some product, product feature, 
or members of some product group. As such, it records 
the identity of the product for which use is authorized 
and specifies the means that will be used by the license 
manager to ensure that the licensee's actual use con- 10 
forms to the terms and conditions of the license. Figure 
1 8 illustrates a syntax diagram for a ProductUse Author- 
ization. Product-id identifies the name of the producer 
of the product or product feature of which usage rights 
are being granted as well as the name of that product; is 
in addition, issuers of product use authorizations may 
specify a range of versions and/or releases whose use 
is controlled by the specific product use authorization. 
Units-granted - Contains the number of units of product 
use which are granted by the license. Management-pol- 20 
icy defines the policy which is to be used in managing 
the granted software usage rights; this definition speci- 
fies the Style, Context-Template, Duration, and License 
Unit Requirements Determination Method which must 
be used. The calling-authorizations and caller-authori- 2s 
zations are as explained above in reference to calling 
cards. The execution-constraints field identifies con- 
straints placed on the characteristics of execution con- 
texts which may be authorized to benefit from the units 
granted by this Product Use Authorization. The product- 30 
token filed contains product specific data not interpreted 
in any way by any processors conformant with the ar- 
chitecture; software product producers 28 use this array 
to augment the capabilities of conformant license man- 
agers. 35 
[0111] Some anticipated uses of the token field in- 
clude language support, detailed feature authorizations, 
and product support number. For language support, a 
token could be constructed which contains a list of local 
language interface versions whose use is authorized; 40 
thus, if a product were available in English, German, 
French and Spanish, a token could be constructed list- 
ing only English and German as the authorized languag- 
es. For detailed feature authorizations, some license is- 
suers will wish to have very fine control over the use of 45 
features in a complex product; however, they may not 
wish to issue a large number of individual Product Use 
Authorizations to "turn on' each feature, so these ven- 
dors could construct tokens which contain lists of the 
features authorized or whose use is denied. For product so 
support number, some issuers may wish to include on 
the product use authorization, and thus make available 
to the running product, some information concerning the 
support procedures for the product; for example, an is- 
suer might include the telephone number of the support ss 
center or a support contract number, and the product 
could be designed to retrieve this data from the license 
manager and display it as part of Help dialogues. 



[0112] The LURTs or license use requirements tables 
of Figure 4 provide a means by which issuers of licens- 
es, whose LURDM is dependent on the type of platform 
on which the product is run, can store information de- 
scribing the relationship between the platform type and 
unit requirements. A syntax diagram for a LURT is 
shown in Figure 1 9. In Figure 20, an example of howthe 
LURT of Figure 4 might be encoded is illustrated. Lurt- 
name specifies the name by which the LURT is to be 
known to conforming license managers. The rows field 
models a list of multicolumn lurt rows. Platform-id iden- 
tifies the platform for which this LurtRow provides li- 
cense unit requirements. The lurt-columns field pro- 
vides a list of one or more lurt column values; the first 
value provided is assigned to column-1 of the lurt-row, 
the second value provided is assigned to column- etc. 
A lurt column value of -1 indicates that use of the product 
or feature is not authorized, while a lurt column value of 
0 or greater indicates the number of units that must be 
allocated in order to authorize product use on the plat- 
form described by this lurt-row. All unspecified columns 
(e.g., columns whose number is greater than the 
number of column values provided in the lurt columns 
element) will be considered to contain the value -1 . 
[0113] In reference to Figure 1 9, to use the row-selec- 
tor feature mentioned above, the platform-ID element 
would be replaced with row-selector which would be im- 
plicit of Context. Also, in Figure 34 described below, in 
the lurdm-kind element, row-selector would be included 
if the row-select feature is to be used. 
[0114] As discussed above, Figure 4 provides an ex- 
ample of a hypothetical LURT, illustrating the LURT 
mechanism, where the issuer of this LURT table has es- 
tablished three unit requirement tiers for use in deter- 
mining the unit requirements for that issuer's products. 
Figure 20 provides an example of how the LURT pre- 
sented in Figure 4 might be encoded. 
[0115] A group definition is used to define and name 
a license group. Once so defined, the name of this group 
can be used on product use authorizations in the same 
manner as a product name. Since a single product use 
authorization specifies the management policy for all 
members of the group, the members of that group must 
be compatible in their licensing styles, i.e., a personal 
use type product can not be mixed with a concurrent use 
product in the same group. Figure 21 shows a group 
definition syntax diagram. Group-name is the name 
which must appear on Product Use Authorizations for 
this group Group-version specifies the current version 
of this group; the requirements for matching between 
the version information on a product use authorization 
and that on a specified group definition are the same as 
those rules which require matching between produce 
use authorizations and the Release Date data provided 
by products. Group-members lists those products or 
features which are components of the named group 
[0116] A key registration is used by a producer 28 or 
issuer 25 who have been registered as authorized li- 
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cense issuers and provided with an appropriate public 
and private key pair. The key registration identifies the 
public key which is to be used by conforming license 
managers 10 in evaluating signatures 53 created by the 
named issuer 25 or producer 28. A key registration syn- s 
tax diagram is shown in Figure 22. Key-owner-name 
provides the name which must be used in either of, or 
both, of the Producer and Issuer fields of license data 
generated by the issuer; the keyowner-name must be 
identical to that specified in the Issuer field of the header io 
record Key-algorithm identifies the registered algorithm 
that is to be used when producing digital signatures with 
this key. Key-value identifies the public key. 
[0117] An issuer delegation is typically issued by a 
producer 28 and authorizes the named issuer 25 to is- is 
sue licenses for products produced by the producer. An 
issuer delegation syntax diagram is shown in Figure 23. 
Delegated-issuer-name identifies the name which must 
appear in the Issuer field of any Product Use Authoriza- 
tion generated using the License Issuer Delegation. Del- 20 
egated-product-id identifies the products whose licens- 
es the named issuer is authorized to issue. Delegated- 
un its-granted, if specified, indicates that the use of this 
IssuerDelegation is to be managed in the style of a con- 
sumptive license; the value of this attribute gives the 25 
number of units for which license documents may be 
generated (i.e., if granted 1000 units by a Producer, an 
Issuer can only issue 1000 units.) Template-authoriza- 
tion provides a "template" Product Use Authorization 
whose attribute values must be included on any Product 30 
Use Authorization generated using this IssuerDelega- 
tion; in the case of attributes which have a scalar value 
(i.e., Version, Release Date, etc.), the Issuer may issue 
licenses with more restrictive values than those speci- 
fied on the Template Authorization. Sub-license-permit- 35 
ted indicates whether the Issuer identified on this Issu- 
erDelegation may issue an IssuerDelegation for the del- 
egated-product-id. 

[0118] A license delegation, as shown in a syntax di- 
agram of Figure 24, is used to delegate the right to man- 40 
age license data. Such delegations are created by the 
licensee (by the license manager), if authorized by the 
issuer 28. A backup delegation, also shown in Figure 
24, is used by one license management facility to au- 
thorize another to manage the delegated rights in the 4S 
case that the delegating license manager is not running. 
The delegated-units field specifies the number of units 
whose management is being delegated; this may only 
be specified when a product use authorization is being 
delegated. Delegation-distribution-control defines the so 
mechanisms by which the distribution and refreshing of 
the delegation will be accomplished. Delegatee-execu- 
tion-constraints identifies any constraints which are 
placed on the execution-context of the Delegatee; these 
constraints are applied in addition to those which are a ss 
part of the delegated License Data. Assignment-list 
identifies any assignments of the delegated units that 
must be respected by the delegatee. Delegated-data 



stores a copy of the License Data received from the is- 
suer that is the subject of the delegation; the delegated 
data is not provided when the License Delegation ele- 
ment is included in a Delegation List. 
[0119] The management information or Manage- 
ment! nfo element records information concerning the 
current state of the LicenseData with which it is associ- 
ated. A syntax diagram of the Managementlnfo element 
is shown in Figure 25. The assignments field identifies 
a list of one or more assignments which may be out- 
standing for the units on the associated product use au- 
thorization. Reservations identifies a list of one or more 
reservations which may be outstanding for the units on 
the associated product use authorization. Delegations 
identifies a list of all outstanding delegations. Backup- 
delegations identifies all outstanding backup delega- 
tions, the allocations field provides detailed information 
about outstanding allocations which involve units from 
the associated product use authorization. Registration- 
date is the date on which the License Data was regis- 
tered in the license database. Registrar is the context 
which caused the License Data to be registered. Local- 
comment is a comment field. Termination-date means a 
license defined date after which the license data may 
not be used; this date must be earlier than the end<Jate 
specified in the license data's term record. The extend- 
ed-info field allows additional information concerning 
the state of the LicenseData and its handling by the li- 
cense manager that is not standardized. 
[01 20] The defined types of elements will now be de- 
scribed. These defined type are: 



Allocation 


ManagementPolicy 


Assignment 


Member 


Context 


NamedValue 


DistributionControl 


Named ValueList 


ExecutionConstraints 


ProductID 


IntervalTime 


Signature 


LicenselD 


Term 


LUDRM 


Version 


ManagementConstraints 





[01 21] The allocation element records the information 
concerning a single unit allocation, and is shown in a 
syntax diagram in Figure 26. Allocation-context speci- 
fies the context to which the allocation was made. The 
allocation-lur field specifies the license unit requirement 
which applies to the allocation-context; this license unit 
requirement is calculated without consideration of any 
allocation sharing which may be possible. The alloca- 
tion-group-id field identifies the "allocation -group" for 
the current allocation, in which an unshared allocation 
will always have an allocation group id of 0; allocations 
which utilize shared units will have an allocation group 
id which is shared by all other allocations sharing the 
same units. 
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[0122] The assignment element is shown in syntax di- 
agram in Figure 27. Assigned-units identifies the 
number of units which are assigned Assignment-term 
identifies the start and end of the assignment period. 
Assignee identifies the context to which the assignment 
is made. 

[0123] The context element is shown in syntax dia- 
gram in Figure 28. The SubContext-type field identifies 
the type of subcontext, and this type can be either stand- 
ard or private; if standard, the type value will be taken 
from the standard-subcontext-type enumeration: (a) 
network-subcontext means the subcontext value iden- 
tifies a network; (b) execution<k>main -subcontext 
means the subcontext value is the name of the manage- 
ment domain within which the caller is executing; (d) 
login-domain-subcontext means the subcontext value is 
the name of the management domain within which the 
user of the caller was originally authenticated or 'logged 
in"; (d) node-subcontext means the subcontext value is 
the name of a node; (e) process-family-subcontext 
means the subcontext value is an implementation spe- 
cific identifier for a group of related processes; (f) proc- 
ess-ID-subcontext means the subcontext value is an im- 
plementation specific process identifier; (g) user-name- 
subcontext means the subcontext value is a user name; 
(h) product-name-subcontext means the subcontext 
value is the same as the product name found on the 
Product Use Authorization; (i) operating-system-sub- 
context means the subcontext value is a character string 
representation of the name of the operating system; (j) 
platform-ID-subcontext means the subcontext value is 
an identifier that describes the hardware platform sup- 
porting the context. The subcontext-value field is the val- 
ue of the subcontext. 

[0124] As discussed above, license data is always 
used or allocated within, or for the benefit of, some 
named licensing context. This context name is con- 
structed by concatenating the values of all subcontexts 
into a single context name. A Context Template speci- 
fies those components of the context name which 
should be used in calculating license unit requirements. 
The management system determines the need to per- 
form a unit allocation each time license units are re- 
quested. The full context on whose behatf the allocation 
should be made is obtained for each requested author- 
ization. The system will mask the full context to exclude 
all sub-contexts not specified in the context template 
and then determine if the resulting context already has 
units allocated to it. If not, units will be allocated accord- 
ing to the specification of the LURDM, otherwise, the 
units previously allocated will be shared by the new con- 
text. Thus, if a given product authorization contains a 
context specification of NODE + USER_NAME, each 
context which requests license unit allocations and 
which has a unique pair of NODE + USE RENAME sub- 
context values will require an explicit grant of license 
units to be made On the other hand, any contexts which 
share the same pair of NODE and USER_NAME sub- 
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context values will be able to "share" a single allocation 
of license units. The requirement for specific allocations 
of units and the ability to share units is exhibited in Fig- 
ure 29 which attempts to provide a "snapshot" of the 

5 units allocated for the product FOOBAR V4.1 at a par- 
ticular instance. It is seen from the figure that although 
presented with five unique full contexts, only four of 
them are unique when looking only at those portions of 
each context which are described by the Context Tem- 

io plate (ie: NODE + USER JsJAME). A unit allocation must 
be made for each of the four instances of unique con- 
texts, when masked by the Context Template. The fifth 
context can share allocated units with another context. 
Thus, the total requirement to support product use as 

15 described in this example would be 40-units (ie: four al- 
locations of ten units each). Significant changes in the 
unit requirements can be achieved by making small 
modifications to the Context Template. Figure 30 shows 
the same contexts as in Figure 29 but a 

20 Context_Template of NODE. The total unit requirement 
for this example would be three units (three allocations 
of ten units each) rather than the forty units required in 
the previous example. 

[0125] The distribution control element defines the 

25 mechanism that will be used for distributing the subject 
delegation and records some status information con- 
cerning the distribution of that delegation. A syntax dia- 
gram of the distribution control element is shown in Fig- 
ure 31. Distribution-method identifies the means by 

30 which the delegation will be distributed, and the alterna- 
tives are refresh-distribution, initial =distributiononly, 
and manual-distribution. Refresh-distribution means the 
license manager shall be responsible for the initial dis- 
tribution of the delegation and for ensuring that refresh 

35 delegations are properly distributed. lnitial<iistribution- 
only means the license manager shall be responsible 
for the initial distribution of the delegation, however, dis- 
tribution of refresh delegations will be made by some 
other means. Manual-distribution means the distribution 

40 of the delegation will be under the control of some other 
mechanism (perhaps a license asset manager). Cur- 
rent-start-date is the time that the last successful initial 
or refresh delegation distribution was performed Cur- 
rent-end-date identifies the last date on which the most 

45 recent delegation distribution was performed. Refresh - 
interval identifies the period of time between attempts 
to refresh the delegation; the refresh -interval may not 
be longer than the maximum-delegation-period and 
should normally be less than that in order to ensure that 

50 refresh delegations are distributed prior to the expiration 
of the previous delegations that they are replacing. Re- 
try-interval identifies the amount of time to wait for an 
unsuccessful distribution attempt to try again. Maxi- 
mum-retry-count identifies the maximum number of 

55 times that an unsuccessful distribution attempt may be 
retried. Retries-attempted records the number of unsuc- 
cessful retry attempts which have been made since the 
last successful initial or refresh delegation distribution 
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was performed. 

[0126] The execution constraints elements place lim- 
its on the environments and contexts which may receive 
allocations. A syntax diagram of the execution con- 
straints element is shown in Figure 32. Operating-sys- 
tem contains a list of zero or more operating systems 
on which the use of the subject license is authorized; if 
no operating systems are specified, it is assumed that 
license use is authorized on all operating systems. Ex- 
ecution-context specifies a list of zero or more full or par- 
tial context names which identify the contexts within 
which products described by the license data may be 
executed; if no context names are specified, the li- 
censed products may be executed in any context con- 
trolled by the licensee. 

[0127] Environment-list identifies those environments 
within which the licensed product may be used. 
[0128] The interval time element is defined by the syn- 
tax IntervalTime ::= UTCTime. 

[0129] The license ID element uniquely identifies the 
license data it is associated with, and is described by 
the syntax diagram of Figure 33. Here issuer uniquely 
identifies the issuer of the license data as we ll as the 
name space within which the LicenselD Number is 



maintained . While the issuer name will typically be the 
same as the name of the issuer's company or personal 
name, this is not a requirement. For instance: The issuer 
name for Digital Equipment Corporation is "DEC/ an 
abbreviation of the corporate name, \falid contents of 
the Issuer field are maintained in the an Issuer Registry. 
The serial-number provides a unique identification or 
serial numberforthe license data. The amendment field 
is an integer which is incremented each time license da- 
ta is amended by its issuer, with the first version of any 
license data carries the amendment number 0; an 
amendment can only be applied to license data if that 
license data has identical Issuer and Number values 
and an amendment number less than the number of the 
amendment to be applied. 

[0130] The license units requirements determination 
method or LURDM element is shown in syntax diagram 
in Figure 34. The combination-permitted field indicates 
whether conforming license managers are permitted to 
combine together into a common pool the units from dif- 
ferent product use authorizations if those produce use 
authorizations have the same product record value; for 
example, if combination is permitted and a single license 
manager discovers in its database two 500-unit author- 
izations for the use of DEC Cobol, the license manager 
would be permitted to combine these two authorizations 
into a logical grant of 1000 units. The overdraft-limit 
modifies the behavior of a conforming license manage- 
ment facility in those cases where it is found that there 
are zero or fewer license units available for use at the 
time of a request for the allocation or consumption of 
additional license units. Operation of overdraft is differ- 
ent depending upon whether allocative, or consumptive 
style is being used. In using with allocative style, an al- 



location is granted even though the remaining units are 
zero or less, up to the overdraft-limit. In using with con- 
sumptive style, the license is authorized to accumulate 
a negative balance of license units, up to the overdraft- 
5 limit. Overdraft-logging-required indicates whether all li- 
cense grants which are the result of overdraft use must 
cause a log record to be generated. When the alloca- 
tion-size field is non-zero, then all unit allocations and 
delegations must be made in sizes which are whole 

10 number multiples of the allocation-size value. Lurdm- 
kind identifies the method by which license unit require- 
ments will be calculated once the requirement for an al- 
location has been discovered, the permitted alternatives 
being (a) LUFTT which specifies that license unit require- 

*5 ments are to be determined by lookup in the LURT which 
is associated with the current license, (b) Constant 
which specifies that license unit requirements are con- 
stant for all platforms on which the licensed product or 
product feature may run, and (c) Private-LURDM which 

20 specifies that license unit requirements are to be deter- 
mined by the licensed product, not by the license man- 
agement facility. The named-lurt-id specifies the name 
of the LURT table to be used in determining license unit 
requirements if the LURDM-kind is specified as LURT; 

25 if the LURDM-kind is specified as LURT and no table is 
explicitly named, the name of the table to be used is con- 
structed from the issuer name on the product use au- 
thorization. Lurdm-value specifies the LURT column to 
be used when LURDM-kind = LURT; however, when 

30 LURDM-kind = Constant, the Lurdm-value field contains 
the precise number of units to be allocated or con- 
sumed. Default-unit-requirement specifies the unit re- 
quirement value to be used when the appropriate LURT 
does not have a row corresponding to the appropriate 

35 platform ID; when specified on a product use authoriza- 
tion with Style - Allocative, the context template will 
change to Process + Product_Specific and the Duration 
will change to Transaction in cases of unrecognized 
Platform ID's. 

*o [0131] The management constraints element is 
shown in a syntax diagram in Figure 35. The manage- 
ment-context field specifies a list of zero or more partial 
context names which identify the specific contexts within 
which the license data may be managed. If no manage- 

45 ment contexts are specified, the license data may be 
managed within any context controlled by the licensee. 
The contexts used in specifying Management Context 
Constraints may only contain the Network, Domain, and 
Node subcontexts. Specifying a list of management 

^0 contexts does not effect whether or not the license data 
can be used within other contexts. For example, unless 
otherwise restricted, license data with a specified man- 
agement context can be remotely accessed from or del- 
egated to other nodes in a network. The management- 

55 scope field defines the maximum permitted size of the 
license management domain within which the license 
data may be managed or distributed, these being single- 
platform, management-domain, or entire-network. Sin- 
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gle-platform constrains the license management do- 
main for the subject license data to be no larger than a 
single platform. Management-domain constrains the li- 
cense management domain for the subject license data 
to be no larger than a single management domain. En- 
tire-network constrains the license management do- 
main for the subject license data to be no larger than a 
single wide area network; that network which contains 
the platform on which the license units were initially 
loaded. Although technology may not exist to detect the 
interorganizational boundaries of a wide area network 
(i.e., what is on the Internet as opposed to being on a 
company's own network), the assumption is that inter- 
organization and internetwork sharing of licenses will 
normally be considered a violation of license terms and 
conditions. The backup-permitted field indicates if the 
Issuer has authorized the use of backup delegations for 
this data. Delegation-permitted indicates if the Issuer 
has authorized the licensee to delegate this data. Max- 
imum-delegation-period identifies the longest interval 
during which a delegation may be valid; by default, del- 
egations have a life of 72-hours. 
[01 32] The major elements of the management policy 
specification are shown in Figure 3, as previously dis- 
cussed. A syntax diagram for the management policy 
element is shown in Figure 36. For the Style field, three 
fundamental styles of license management policy are 
supported, allocative, consumptive, and private-style, 
as explained above. Only one of these styles may be 
assigned to any single product use authorization. The 
Context-template specifies those components (sub- 
contexts) of the execution-context name which should 
be used in determining if unit allocations are required. 
The Duration defines the duration of an allocation of li- 
cense units to a specific context or the duration of the 
period which defines a valid consumptive use. For du- 
rations of type "Assignment," the specification of a Re- 
assignment Constraint is also provided for. Three types 
of Duration_Kind are supported, these being Transac- 
tion, Assignment and Immediate, as explained above. 
The lur-determination-method stores information used 
in calculating the number of units that should be allocat- 
ed or consumed in response to a license request. The 
al location -sharing-limit identifies the largest number of 
execution contexts that may share an allocation made 
under this management policy; an allocation-sharing- 
limit of 0 indicates that the number of execution contexts 
that may share an allocation is unlimited. The reassign- 
ment-constraint specifies a minimum duration of assign- 
ment; although there is normally no constraint placed 
on how frequently granted units may be reassigned, an 
issuer may constrain reassignment by specifying this 
minimum duration of an assignment, in which case re- 
assignment of assigned units will not be supported until 
the amount of time specified in the Reassignment Con- 
straint has passed. If an assignment of some particular 
set of units has been delegated and the delegation pe- 
riod for that delegation has not terminated, cancellation 



of the delegation must be performed prior to reassign- 
ment. 

[0133] The member element identifies a specific li- 
censed product which may be part of a calling authori- 

s zation or group definition, and is shown in syntax dia- 
gram in Figure 37. Member-product identifies the prod- 
uct which is a member. Member-signature is construct- 
ed from the product and token fields of the called mem- 
ber structure as well as the product and issuer fields of 

10 the calling product. Member-token provides the data 
which should be used as the product token for this mem- 
ber. 

[0134] Named values are data elements with a char- 
acter string tag that identifies the data element, and 

75 have a syntax as shown in Figure 38, which also shows 
the syntax for ValueData and named value list. A named 
value list models a list of named values, with an example 
being shown in Figure 39. In Figure 38, value-Name 
uniquely identifies the value; no standard value names 

20 are defined, and the period character can be used as a 
part of the value name to form a hierarchical tag registry 
at the discretion of the issuer. Value-data is the data that 
has been named; data types are selected from the pos- 
sible Value Data types, seen in the Figure, value- 
rs boolean means the named data is a boolean value. Val- 
ue-integer means the named data is an integer value. 
Value-text means the named data is a StringList value. 
Value-general means the named data is a stream of 
bytes in any format. Value-list means the named data is 

30 a list of named data values. 

[0135] The product ID explicitly identifies the product 
which is the subject of the license data with which it is 
associated, with the syntax for ProductID being shown 
in Figure 40. The version and release date fields provide 

35 a mechanism for defining which specific instances of the 
licensed product are described in the associated license 
data. The Producer field is a registered name which 
identifies the producer of the licensed feature; in the 
case of Group Names, the Producer is always also the 

40 Issuer of the group. The Product-name identifies a li- 
censed software feature. The First-version identifies the 
earliest version of the product whose use is authorized. 
The Last-version identifies the latest version of the prod- 
uct whose use is authorized. The First-release-date 

45 identifies the earliest release of the product whose use 
is authorized. The Last- release-date identifies the latest 
release of the product whose use is authorized. Con- 
forming license managers are required to interpret the 
contents of these fields in the most restrictive way pos- 

50 sible. Thus, if a license is issued with Last -version = 3.0 
and a Last-release-Date of 1-Jan-1 991 , then the use of 
version 2.0 of the licensed product would be unauthor- 
ized if it had a release date of 2-Jan-1 991 If either a 
First version or First- re lease-date is specified without a 

55 matching Last-version or Last-release-date, use of the 
produce is authorized for all versions or release dates 
following that specified. Similarly, if either a last-version 
or Last- release-date is specified without a matching 
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First-version or First-release-date, use of the produce 
is assumed to be authorized for all versions or release 
dates prior to that specified. Issuers should typically only 
specify one of either First-version or First-release-date. 
This is the case since it is anticipated that these fields 5 
will typically refer to events which occurred prior to the 
moment of license data issuance. Thus, it should nor- 
mally be possible for the issuer to state unambiguously 
with only one of these two fields which is the oldest im- 
plementation of the product that is to be authorized The to 
architecture does permit, however, both fields to be 
used In a single product authorization. 
[0136] The signature element is used to establish the 
integrity and authorship of the license data with which it 
is associated. A syntax diagram for the signature ele- 15 
ment is shown in Figure 41. The Signature-algorithm 
field identifies the registered algorithm that was used to 
produce the digital signature. Signature-parameters are 
the values of the algorithm's parameters that are to be 
used; the need for and syntax of parameters is deter- 20 
mined by each individual algorithm. Signature-value is 
an enciphered summary of the information to which the 
signature is appended; the summary is produced by 
means of a one-way hash function, while the encipher- 
ing is carried out using the secret key of the signer (Is- 25 
suer). 

[0137J The term element defines an interval during 
which the license data is valid, and is shown in syntax 
diagram form in Figure 42. The fields are start -date and 
end-date. Start-date identifies the first date of the term; 30 
if not specified, the license data is considered valid on 
any date prior to the end-date. End-date identifies the 
last date of the term; if not specified, the license data is 
considered valid on any date after the Start-date. While 
the Start-date is always either omitted or specified as 35 
an absolute date, the End-date can be either absolute 
or relative. If the End-date is specified as a relative or 
"interval" date and the Start-date has been omitted, the 
date of license registration will be used as the effective 
start date in computing the valid term of the license data. 40 
It should be noted that the system does not specify the 
mechanism by which system dates are maintained by 
platforms supporting system components. Instead, the 
system always accepts that system time returned to it 
as correct. Thus, the reliability of the management of 45 
license data which specifies terms is dependent on the 
lime management function of the underlying platform. 
[0138] The version element identifies a four-part ver- 
sion of the licensed software product or feature. A syn- 
tax diagram of the version element is shown in Figure so 
43. The schematics of each of the four parts is not de- 
tailed, but it is required that producers who wish to per- 
mit version ranges to be specified on product use au- 
thorizations ensure that the collating significance of the 
lour parts is maintained. When comparing versions, 55 
Part-1 is considered first, then Part-2, then Part-3, and 
finally, Part -4 Part-1 identifies a major modification to 
the versioned object. Part-2 identifies a modification to 



the versioned object which is less significant than a 
modification which would cause a change in the Part-1 
value. Part-3 identifies a modification to the versioned 
object which is less significant than a modification which 
would cause a change in the Part-2 value. Part-4 iden- 
tifies a modification to the versioned object which is less 
significant than a modification which would cause a 
change in the Part-3 value. 

FILTERS 

[0139] An important feature is the use of filters in the 
license management program 11, including the client in- 
terface 31 and the management interface 33. A filter is 
used is select items in the license database 23, for ex- 
ample. Various selection mechanisms are used in pick- 
ing out or doing lookups in database technology; filters 
are one of them. The filter engine used in the license 
management system 11 of Figure 1 is generally of a 
known construction, with the exception of the select filter 
item type as will be described, which allows a complex 
rather than a flat data format to be selected from. The 
feature that is of importance to this embodiment is the 
way of specifying items as an input to the filter function, 
rather than the filter function itself. Thus, there is de- 
scribed below a template for specifying input to the filter 
engine. This is as if a form were used as the input, with 
blanks on the form; by filing in certain blanks these 
would be the items selected on, the blanks not filled in 
would be "donl care'. 

[0140] An instance of the class filter is a basis for se- 
lecting or rejecting an object on the basis of information 
in that object. At any point in time, a filter has a value 
relative to every object - this value is false, true or un- 
defined. The object is selected if and only if the filter's 
value is true. This concrete class has the attributes of 
its superclass - Object - and the specific attributes listed 
in the table of Figure 44. 

[0141] A filter is a collection of simpler filters and ele- 
mentary filter-items together with a Boolean operation. 
The filter value is undefined if and only if all the compo- 
nent filters and filter-items are undefined. Otherwise, the 
filter has a Boolean value with respect to any object, 
which can be determined by evaluating each of the nest- 
ed components and combining their values using 
Boolean operation (components whose value is unde- 
fined or ignored). The attributes specific to filter as 
shown in Figure 44 are (a) filter items which are a col- 
lection of assertions, each relating to just one attribute 
of an object, (b) filters which are a collection of simple 
filters, and (c) filter type which is the filter's type, of one 
of the following values: And, Or, Not. 
[01 42] An instance of the class filter item is a compo- 
nent of a filter. It is an assertion about the existence or 
values of a single attribute of a license data object or 
one or its subobjects This concrete class has the at- 
tributes of its superclass - object - and the specific at- 
tributes listed in the tabic of Figure 45 
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[0143] The value of a filter item is undefined if: (a) the 
Attribute Types are unknown, or (b) the syntax of the 
Match Value does not conform to the attribute syntax 
defined for the attribute type, or (c) a required Attribute 
is not provided. The attributes specific to filter item as 
shown in Figure 45 are (a) filter item fypewhich identifies 
the type of filter item and thereby the nature of the filter, 
and its value must be one of 



equality 


less 


inequality 


present 


greater or equal 


select 


less or equal 


request candidates 


greater 


simulate request 



(b) attribute type which identifies the type of that at- 
tribute whose value or presence is to be tested; the val- 
ue of All Attributes may be specified, (c) match value 
which is the value which is to be matched against the 
value of the attribute, (d) filter which identifies the filter 
to be used in evaluating a selected subobject of the cur- 
rent object; the filter is ignored if the filter item type is 
not select or if the specified attribute type is not present 
in the object, and upon evaluation of the filterXUe value 
of filter item will be set to that of the filter, (e) initial sub- 
string, if present, this is the substring to compare against 
the initial portion of the value of the specified attribute 
type, (f) substring, It present, this is the substring(s) to 
compare against all substrings of the value of the spec- 
ified attribute type, (g) final substring, if present, this is 
the substring to compare against the final portion of the 
value of the specified attribute type, and (h) license re- 
quest, if present, this is license request against which 
the appropriate license data objects should be evaluat- 
ed; this attribute may only be specified if the value of the 
filter item type is either Request Candidates or Simulate 
Request. 

[0144] An instance of enumeration syntax Filter Type 
identifies the type of a filter. Its value is chosen from one 
of the following: (a) And means the filter is the logical 
conjunction of its components; the filter is true unless 
any of the nested filters or filter items is false, or if there 
are no nested components, the filter is true; (b) Or 
means the filter is the logical disjunction of its compo- 
nents; the filter is false unless any of the nested filters 
or filter items is true, or, if there are no nested compo- 
nents, the filter is false; (c) Not means the result of the 
filter is reversed; there must be exactly one nested filter 
or filter item, and the filter is true if the enclosed filter or 
filter item is false, and is false if the enclosed filter or 
filter item is true. 

[0145] An instance of enumeration syntax Filter Item 
Type identifies the type of a filter item. Its value is chosen 
from one of the following: (a) Equality which means the 
filter item is true if the object contains at least one at- 
tribute of the specified type whose value is equal to that 
specified by Match Value (according to the equality 



matching rule in force), and false otherwise; (b) Inequal- 
ity which means the filter item is true if the object con- 
tains at least one attribute of the specified type whose 
value is not equal to that specified by Match Value (ac- 
5 cording to the equality matching rule in force), and false 
otherwise; (c) Greater or Equal which means the filter 
item is true if the object contains at least one attribute 
of the specified type whose value is equal to or greater 
than the value specified by Match Value (according to 
10 the matching rule in force), and false otherwise; (d) Less 
or Equal which means the filter item is true if the object 
contains at least one attribute of the specified type 
whose value is equal or less than the value specified by 
Match Value (according to the matching rule in force), 

15 and false otherwise; (e) Greater which means the filter 
item is true if the object contains at least one attribute 
of the specified type whose value is greater than the val- 
ue specified by Match Value (according to the matching 
rule in force), and false otherwise; (f) Less which means 

20 the filter is true if the object contains at least one attribute 
of the specified type, whose value is less than the value 
specified by Match Value (according to the matching 
rule in force),and false otherwise; (g) Present which 
means the filter item is true if the object contains at least 

2$ one attribute of the specified type, and false otherwise; 
(h) Select which means the filter item is true if the object 
contains at least one attribute of the specified type which 
has an object syntax and when the Filter is evaluated 
against the attributes of that object the Filter is true, and 

30 false otherwise; (i) Request Candidates which means 
the filter item is true if the object against which it is eval- 
uated is one which could be used to provide some or all 
of the units requested by the specified License Request; 
the evaluation is made independently of any outstand- 

35 ing allocations or preallocations; and (j) Simulate Re- 
quest which means the filter item is true if the object 
against which it is evaluated is one which would be used 
to provide some or all of the units requested by the spec- 
ified License Request. 

40 [0146] The Request Candidates and Simulate Re- 
quest filter item types are of special use in testing and 
prototyping of systems by a license manager at a licen- 
see's site. For example, the license manager can sim- 
ulate the effect of potential assignments, the effect of a 

45 population of certain types on a network, etc. 

[0147] As an example, Figure 46 shows how a filter 
may be constructed to identify "All Product Use Author- 
izations issued by Digital for the Product 'Amazing 
Graphics System' which contains a calling authorization 

50 for Digital's 'Amazing Database* Product'. This example 
is in the international standard format referred to as X. 
409 as mentioned above. 

[01 48] Filters can also be used in a request allocation, 
being specified in a request extension as explained 
55 above. That is, a filter is one of the optional items in a 
request extension For example, if a user wanted to use 
a version of WordPerfect with French language exten- 
sion, and there were version with and without on the net- 
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work, his request allocation would have a request ex- 
tension that specified a fitter for "French" in the token 
field. In this manner, a product can describe itself more 
richly. The filter in the request extension can be a Re- 
quired filter or a Preferred filter, meaning the feature 
such as "French" is either absolutely necessary, or 
merely the preferred. 



Claims 

1. A method of managing use of licensed software 
items (17), said software items separately execut- 
able on a computer system (16) or accessible by 
said computer system, the computer system includ- 
ing a processor (10) and one or more nodes (16), 
comprising the steps of : 

maintaining by said processor (10) a store (23) 
of license authorizations (35) for said software 
items; each license authorization including an 
indication of license management policy for a 
software item, said indication having a plurality 
of sets of policy components (43-46), said sets 
of policy components granting specified restric- 
tive rights to execute or access said software 
items by said nodes; said specified restrictive 
rights including sets of restrictions in at least 
context (44) of use and duration (45) of use of 
a software item; said policy components of 
each set providing alternatives in rights to exe- 
cute or access said software items by one or 
more nodes in said computer system; said li- 
cense authorizations being received by said 
processor (10) for storing in said store (23), 
from a license grantor (25,28) external to said 
processor; and 

accessing said store by said processor using 
management functions executed on said proc- 
essor to identify a license authorization in said 
store, and to modify in said store one or more 
of said specified restrictive rights of said policy 
components of the identified license authoriza- 
tion. 

2. A method according to claim 1 including the steps 
of : 

sending from one of said nodes (16) to said 
processor (10) a request by a user of one of 
said software items (17) to obtain permission to 
use said software item; said request identifying 
the user and said software item; and 
accessing said store by said processor to ob 
tain information from said license authorization 
for said software item, in response to said re- 
quest, and comparing said identification of said 
user and said software item with said informa- 



tion, to produce a grant or refusal of said re- 
quest for sending by said processor to said us- 
er. 

5 3. A method according to claim 2, wherein said re- 
quest is in the form of a remote procedure call, and 
said grant or refusal sent to said user is a return of 
said procedure call. 

io 4. A method according to claim 1 , whereby said policy 
components include a termination date (40), and 
said management functions can modify said termi- 
nation date to an earlier termination date. 

15 5. A method according to claim 1 , wherein said policy 
components include a right of delegation (48) of a 
right to grant said requests to another server, and 
said management functions can modify said right of 
delegation to remove said right of delegation. 

20 

6. A method according to claim 1 , including storing in 
association with said license authorization (35) a 
number of management attributes (40-51 ) and said 
management functions being able to modify said 

25 management attributes. 

7. A method according to claim 1 , wherein said spec- 
ified restrictive rights include a set (44) of restric- 
tions in context of use of a software item, said set 

30 including identification of network, user name, proc- 
ess, operating system and platform. 

8. A system executable on a computer for managing 
use of a plurality of licensed software products (17), 

35 said software products operable separately from 
said system, said system comprising : 

means (1 1 ) executing on said computer (10) for 
maintaining and accessing a store (23) of li- 
40 cense documents (35), one document for each 

said product (17); each license document in 
said store including an indication of license pol- 
icy, said indication having a plurality of sets of 
policy components (43-46); said policy compo- 
45 nents granting specified restrictive rights to use 

said software products; said specified restric- 
tive rights including at least restrictions in con- 
text (44) of use and duration (45) of use of a 
software product; each said set of said policy 
50 components providing different alternatives for 

said restrictive rights; and 
a management interface (33) executable on 
said computer (1 0) for accessing said store (23) 
to modify selected ones of said policy compo 
55 nents of an identified license document 

9. A system according to claim 8 including : 
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means (18) executable on a processor (16) for 
sending a request from a user of one of said 
products (17) to obtain permission to use said 
product; said request identifying the user and 
said product; and s 
means executable on said computer (10) for 
accessing said store (23) to obtain information 
from said license document for said product, in 
response to said request, and for comparing 
said identification of said user and said product 10 
with said information, and with constraints im- 
posed by said policy components, to produce 
a grant or refusal of said request and send grant 
or refusal to said user. 

15 

10. A system according to claim 9, wherein said means 
for maintaining, and said means for accessing and 
sending to said user are all located at a server 
(10,13) on a distributed network, and said means 
(18) for sending a request is located at a user node 20 
(16) on said network. 

11. A system according to claim 10, wherein said li- 
cense document (35) is a data arrangement speci- 
fied as a product use authorization, and said prod- 2s 
uct use authorization is received by said server from 

a license issuer (25,26,28). 

12. A system according to claim 8, wherein said policy 2. 
components include a termination date (40), and 30 
said management functions can modify said termi- 
nation date to an earlier termination date. 

13. A system according to claim 8 including means for 
storing in association with said license authorization 35 
a number of management attributes (40-51), and 
said management functions being able to modify 
said management attributes. 

40 

Patentanspruche 

1. Verfahren zum Managen einer Anwendung lizen- 
sierter Software-Elemente (17), wobei die Soft- 
ware-Elemente auf einem Computersystem (16) 45 
einzeln ausfuhrbar sind oder einzeln auf sie durch 
das Computersystem zugegriffen werden kann, wo- 
bei das Computersystem einen Prozessor (10) und 
einen oder mehrere Knoten (16) enthalt, und das 3. 
Verfahren folgende Schritte aufweist: so 

Unterhalten eines Speichers (23) von Lizenz- 
Zugriffsberechtigungen (35) fur die Software- 
Elemente durch den Prozessor (10); wobei je- 
de Lizenz-Zugriffsberechtigung eine Anzeige 55 4. 
einer Lizenz-Managementpolice fOr ein Soft- 
ware-Element enthalt, wobei die Anzeige eine 
Vielzahl von Gruppen von Police-Komponen- 



ten (43-46) hat, wobei die Gruppen von Police- 
Komponenten spezifizierte beschrankte Rech- 
te zum Ausfuhren der oder zum Zugreifen auf 
die Software-Elemente durch die Knoten ge- 
wahrt; wobei die spezifizierten beschrankten 
Rechte Gruppen von Bosch rankun gen wenig- 
stens in bezug auf einen Kontext (44) einer An- 
wendung und einer Dauer (45) einer Anwen- 
dung eines Software-Elements enthalt; wobei 
die Police-Komponenten jeder Gruppe Alterna- 
tiven in bezug auf Rechte zum Ausfuhren der 
oder zum Zugreifen auf die Software-Elemente 
durch einen oder mehrere Knoten im Compu- 
tersystem zur Verfugung stellen; wobei die Li- 
zenz-Zugriffsberechtigung en durch den Pro- 
zessor (10) zur Speicherung im Speicher (23) 
von einem Lizenzgeber (25, 28) empfangen 
werden, der extern zum Prozessor ist; und 
Zugreifen auf den Speicher durch den Prozes- 
sor unter Verwendung von Management-Fun k- 
tionen, die auf dem Prozessor ausgefuhrt wer- 
den, urn eine Lizenz-Zugriffsberechtigung im 
Speicher zu identifizieren, und um im Speicher 
eines oder mehrere der spezifizierten be- 
schrankten Rechte der Police-Komponenten 
der identifizierten Lizenz-Zugriffsberechtigung 
zu modifizieren. 

Verfahren nach Anspruch 1, das folgende Schritte 
enthalt: 

Senden einer Anfrage von einem der Knoten 
(16) zum Prozessor (1 0) durch einen Anwender 
eines der Software-Elemente (17), um eine Er- 
laubnis zum Anwenden des Software-Ele- 
ments zu erhalten; wobei die Anfrage den An- 
wender und das Software-Element identifiziert; 
und 

Zugreifen auf den Speicher durch den Prozes- 
sor, um Informationen von der Lizenz-Zugriffs- 
berechtigung fur das Software-Element zu er- 
halten, in Antwort auf die Anfrage, und Verglei- 
chen der Identifikation des Anwenders und des 
Software-Elements mrt den Informationen, um 
eine Gewahrung oder eine Zuruckweisung der 
Anfrage zum Senden durch den Prozessor zum 
Anwender zu erzeugen. 

Verfahren nach Anspruch 2, wobei die Anfrage in 
der Form eines entfernten Verfahrens-Aufrufs ist, 
und die zum Anwender gesendete Gewahrung oder 
Zuruckweisung eine Rucksprung des Verfahrens- 
Aufrufs ist 

Verfahren nach Anspruch 1 , wobei die Police-Kom- 
ponenten ein Beendigungs-Datum (40) enthalten, 
und die Management-Funktionen das Beendi- 
gungs-Datum zu einem fruheren Beendigungs-Da- 
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turn modifizieren konnen. 

5. Verfahren nach Anspruch 1 , wobei die Police-Kom- 
ponenten ein Recht eines Ubertragens (48) eines 
Rechts enthalten, um die Anfragen zu ein em ande- 5 
ren Server zu gewahren, und die Management- 
Funktionen das Recht des Ubertragens modifizie- 
ren konnen, um das Recht des Ubertragens zu ent- 
fernen. 

10 

6. Verfahren nach Anspruch 1, das, in Zusammen- 
hang mit der Lizenz-Zugriffsberechtigung (35), ein 
Speichern einer Anzahl von Managementattributen 
(40-51) enthalt, und wobei die Management-Fun k- 
tionen die Managementattribute modifizieren kon- 15 
nen. 

7. Verfahren nach Anspruch 1 , wobei die spezifizier- 
ten beschrankten Rechte eine Gruppe (44) von Be- 
schrankungen im Kontext mit einer Anwendung ei- 20 
nes Software-Elements enthalt, wobei die Gruppe 
eine Identifikation eines Netzwerks, eines Anwen- 
dernamens, eines Prozesses, eines Betriebssy- 
stems und einer Plattform enthalt. 

25 

8. System, das auf ein em Computer ausfuhrbar ist, 
zum Managen einer Anwendung einer Vielzahl li- 
zensierter Softwareprodukte (17), wobei die Soft- 
wareprodukte vom System einzeln betreibbar sind, 
wobei das System folgendes aufweist: 30 

eine Einrichtung (11), die auf dem Computer 
(10)ausfuhrt, zum Unterhalten eines Speichers 
(23) von Lizenzdokumenten (35), und zwar ein 
Dokument fur jedes Produkt (1 7), und zum Zu- 35 
greifen auf ihn; wobei jedes Lizenzdokument im 
Speicher eine Anzeige einer Lizenzpolice ent- 
halt, wobei die Anzeige eine Vielzahl von Grup- 
pen von Police- Komponenten (43-46) hat; wo- 
bei die Police-Komponenten spezifizierte be- 40 
schrankte Rechte zum Anwenden der Soft- 
wareprodukte gewahrt; wobei die spezifizierten 
beschrankten Rechte wenigstens Beschran- 
kungen in bezug auf einen Kontext (44) einer 
Anwendung und eine Dauer (45) einer Anwen- 45 
dung eines Softwareprodukts enthalt; wobei 
die Gruppe der Police-Komponenten unter- 
schiedliche Alternativen fur die beschrankten 
Rechte zur Verfugung stellen; und 
eine Managementschnittstelle (33), die auf so 
dem Computer (10) ausfuhrbar ist, zum Zugrei- 
fen auf den Speicher (23), um ausgewahlte der 
Police-Komponenten eines identifizierten Li- 
zenzdokuments zu modifizieren. 

55 

9. System nach Anspruch 8, das folgendes enthalt: 

eine Einrichtung (18), die auf einem Prozessor 



(16) ausfuhrbar ist, zum Senden einer Anfrage 
von einem Anwender eines der Produkte (17), 
um eine Erlaubnis zum Anwenden des Pro- 
dukts zu erhalten; wobei die Anfrage den An- 
wender und das Produkt identifiziert; und 
eine Einrichtung, die auf dem Computer (10) 
ausfuhrbar ist, zum Zugreifen auf den Speicher 
(23), um Informationen aus dem Lizenzdoku- 
ment fur das Produkt zu erhalten, in Antwort auf 
die Anfrage, und zum Vergleichen der Identifi- 
kation des Anwenders und des Produkts mit 
den Informationen, und mit durch die Police- 
Komponenten auferlegten Einschrankungen, 
um eine Gewahrung oder eine ZurOckweisung 
der Anfrage zu erzeugen und eine Gewahrung 
oder eine ZurOckweisung zum Anwender zu 
senden. 

10. System nach Anspruch 9, wobei die Einrichtung 
zum Unterhalten und die Einrichtung zum Zugreifen 
und zum Senden zum Anwender alle bei einem Ser- 
ver (1 0, 1 3) auf einem verteilten Netzwerk angeord- 
net sind, und die Einrichtung zum Senden einer An- 
frage bei einem Anwenderknoten (16) auf dem 
Netzwerk angeordnet ist. 

11. System nach Anspruch 10, wobei das Lizenzdoku- 
ment (35) eine Datenanordnung ist, die als Produkt- 
anwendungs-Zugriffsberechtigung spezifiziert ist, 
und die Produktanwendungs-Zugriffsberechtigung 
durch den Server von einem Lizenzgeber (25, 26, 
28) empfangen wird. 

1 2„ System nach Anspruch 8, wobei die Police-Kompo- 
nenten ein Beendigungs-Datum (40) enthalten, und 
die Management-Funktionen das Beendigungs- 
Datum zu einem fruheren Beendigungs-Datum mo- 
difizieren konnen. 

13. System nach Anspruch 8, das eine Einrichtung zum 
Speichern einer Anzahl von Managementattributen 
(40-51 ), in Zusammenhang mit der Lizenz-Zugriffs- 
berechtigung, enthalt, und wobei die Management- 
Funktionen die Managementattribute modifizieren 
konnen. 



Revendications 

1 . Procede de gestion de I' utilisation d'elements de lo- 
giciel sous licence (17), lesdits elements de logiciel 
etant executables separement sur un systeme in 
formatique (16) ou etant accessibles audit systeme 
informatique, le systeme informatique comprenant 
un processeur (10) et un ou plusieurs noeuds (16), 
comportant les etapes consistant: 

a maintenir, au moyen dudit processeur (10), 
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une memoire (23) d'autorisations de licence 4. 
(35) relatives auxdits elements de logiciel; cha- 
que autorisation de licence comprenant une in- 
dication de politique de gestion de licences re- 
lative a un element de logiciel, ladite indication s 
comprenant une multiplicity d'ensembles de 
composants de politique (43 a 46), lesdits en- 5. 
sembles de composants de politique accordant 
des droits restrict if s specifies d'execution des- 
dits Elements de logiciel, ou d'acces a ces der- io 
niers, par lesdits noeuds; lesdits droits restric- 
tifs specifies comprenant des ensembles de 
restrictions d'au moins le contexte (44) d'utili- 
sation et la duree (45) d'utilisation d'un Element 6. 
de logiciel; lesdits composants de politique de ?5 
chaque ensemble prevoyant des variantes de 
droits d'execution desdits elements de logiciel, 
ou d'acces a ces derniers, par un ou plusieurs 
noeuds dudit systeme informatique; lesdites 
autorisations de licence 6tant regues par ledit 20 
processeur (10) pour etre emmagasinees dans 7. 
ladite memoire (23), apartird'un moyend'octroi 
de licences (25, 28) externe audit processeur; 
et 

a acceder a ladite memoire au moyen dudit pro- 25 
cesseur a I'aide de fonctions de gestion execu- 
tees sur ledit processeur afin d'identifier une 
autorisation de licence dans ladite memoire, et 
de modifier dans ladite memoire un ou plu- 8. 
sieurs desdits droits restrict if s specifies desdits 30 
composants de politique de ladite autorisation 
de licence identifiee. 

2. Precede selon la revendication 1 , comprenant les 
etapes consistant: 35 

a envoyer de Tun desdits noeuds (16) audit pro- 
cesseur (10) une demande emanant d'un utili- 
sateurde Tun desdits elements de logiciel (17) 
visant a obtenir la permission d'utiliser ledit ele- 40 
mentde logiciel; ladite demande identifiant I'uti- 
lisateur et ledit element de logiciel; et 
a acceder a ladite memoire, au moyen dudit 
processeur, afin d'obtenir des informations a 
partir de ladite autorisation de licence relative 45 
audit element de logiciel, en reponse a ladite 
demande, et a comparer ladite identification 
dudit utilisateur et dudit element de logiciel 
auxdites informations, afin de produire une ac- 
ceptation ou un rejet de ladite demande a en- so 
voyer par ledit processeur audit utilisateur. 

3. Procede selon la revendication 2, dans lequel ladite 
demande se presente sous la forme d'un appel de 
procedure eloigne, et ladite acceptation ou ledit re- 55 
jet envoye(e) audit utilisateur est un retour dudit ap- 
pel de procedure. 



Procede selon la revendication 1 , dans lequel les- 
dits composants de politique comprennent une date 
de cessation (40), et lesdites fonctions de gestion 
peuvent remplacer ladite date de cessation par une 
date de cessation plus avancee. 

Procede selon la revendication 1 , dans lequel les- 
dits composants de politique comprennent un droit 
de delegation (48) d'un droit d'acceptation desdites 
demandes a un autre serve ur, et lesdites fonctions 
de gestion peuvent modifier ledit droit de delegation 
afin de retirer ledit droit de delegation. 

Procecte selon la revendication 1, comprenant la 
memorisation, en association avec ladite autorisa- 
tion de licence (35), d'un certain nombre d'attributs 
de gestion (40 a 51), lesdites fonctions de gestion 
etant capables de modifier lesdits attributs de ges- 
tion. 

Procede selon la revendication 1 , dans lequel les- 
dits droits restrictifs specifies comprennent un en- 
semble (44) de restrictions du contexte d'utilisation 
d'un element de logiciel, ledit ensemble compre- 
nant Identification du reseau, du nom de ['utilisa- 
teur, du processus, du systeme d'exploitation et de 
la plate-forme. 

Systeme executable sur un ordinateur pour gerer 
('utilisation d'une multiplicity de produits logiciels 
sous licence (1 7), lesdits produits logiciels etant ap- 
tes a etre exploites independamment dudit syste- 
me, ledit systeme comportant: 

des moyens (II) executes sur ledit ordinateur 
(10) pour maintenir une memoire (23) de docu- 
ments de licence (35), un document pour cha- 
que ditproduit (17), etpouracceder a ladite me- 
moire; chaque document de licence contenu 
dans ladite memoire comprenant une indica- 
tion de politique de licence, ladite indication 
comprenant une multiplicity d'ensembles de 
composants de politique (43 a 46); lesdits com- 
posants de politique accordant des droits res- 
trictifs specifies d'utilisation desdits produits lo- 
giciels; lesdits droits restrictifs specifies com- 
prenant au moins des restrictions du contexte 
(44) d'utilisation et de la duree (45) d'utilisation 
d'un produit logiciel; chaque dit ensemble des- 
dits composants de politique prevoyant des va- 
riantes differentes desdits droits restrictifs; et 
une interface de gestion (33) executable sur le- 
dit ordinateu/ ( 1 0) pou r acceder a ladite memoi- 
re (23) afin de modifier des composants selec- 
tionnes parmi lesdits composants de politique 
d'un document de licence identified 

Systeme selon la revendication 8, comprenant: 
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des moyens (18) executables sur un proces- 
ses (16) pour envoyer une demande emanant 
d'un utilisateurde I'un desdits produits (17) afin 
d'obtenir la permission d'utiliser ledit produit; la- 
dite demande identifiant I'utilisateur et ledit pro- s 
duit; et 

des moyens executables sur ledit ordinateur 
(10) pour acceder a ladite memoire (23) afin 
d'obtenir des informations a parti r dudit docu- 
ment de licence relatif audit produit, en r6ponse 10 
a ladite demande, et pour comparer ladite iden- 
tification dudit utilisateur et dudit produit auxdi- 
tes informations, et a des contraintes imposees 
par lesdits composants de politique, afin de 
produire une acceptation ou un rejet de ladite is 
demande et d'envoyer une acceptation ou un 
rejet audit utilisateur. 

10. Systeme selon la revendication 9, dans lequel les- 
dits moyens de maintien et lesdits moyens d'acces 20 
et d'envoi audit utilisateur sont tous situes au niveau 
d'un serveur (10, 1 3) sur un reseau reparti, et lesdits 
moyens (1 8) d'envoi d'une demande sont situes au 
niveau d'un noeud d'utilisateur (16) sur ledit reseau. 

25 

1 1 . Systeme selon la revendication 1 0, dans lequel ledit 
document de licence (35) est un agencement de 
donnees specific en tant qu'autorisation d'uttlisation 
de produit, et ladite autorisation d'utilisation de pro- 
duit est recue par ledit serveur a parti r d'un moyen 30 
d'emission de licences (25, 26, 28). 

12. Systeme selon la revendication 8, dans lequel les- 
dits composants de politique comprennent une date 

de cessation (40), et lesdites fonctions de gestion 35 
peuvent remplacer ladite date de cessation par une 
date de cessation plus avancee. 

13. Systeme selon la revendication 8, comprenant des 
moyens pour emmagasiner, en association avec la- 40 
dite autorisation de licence, un certain nombre d'at- 
tributs de gestion (40 a 51), lesdites fonctions de 
gestion etant capables de modifier lesdits attributs 

de gestion. 
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License (Product Use 
j Authorization ) 

Product Name 



Producer 



Version Nos. 



if 



Release Date 



Issuer 



Licensee 



Start Date 



End Date 



Units Granted 



Units Available 



Style 



Context 



Duration 



LURDM 



LURT 



Delegation Auth. 



Calling Auth. 



Combination Auth. 



Overdraft Auth. 



Token: 



Signature 



Check Sum 



36 



-37 

^40 

-41 

-42 

-44 
-45 
-46 
-47 
-48 
-49 
50 
-51 
52 
53 
h54 



I 



License Unit Requirements Table 



Row Selector 


Columns 


Platform ID 


A 


B 


C 


PC-0 


10 


230 


-1 


PC-1 


12 


230 


-1 


VAX 6210 


158 


300 


150 



Style 


Context 


Duration 


i 1 1 

LURDM ] 


Allocative 


Network 


Transaction 


Constant 


Consumptive 


Execution Domain 


Assignment 


Table Lookup 


Private 


LoginDomain 


Immediate 


Private 




Node ID 






ProcessFamily 


FIG3 


Process 


User Name 


Product Name 


Operating System 


Platform ID 


Private 
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Attributes Specific to Filter 


Value 
Initially 


i 


i 






i 


i 




i 


Value 
Number 






■ 

o 


■ 

o 


i 

o 


0 or more 


0-1 or 
more 


i 

o 


Value 
Length 


i 


t 


■ 


■ 


1 or more 


1 or more 


1 or more 


1 


Value 
Syntax 


Enum(Filter Item Type) 


<D 

>* 
h» 


any 


Object(Filter) 


String! •) 


String(*) 


String! •) 


Object(License Request) 


Attribute 


Filter Item Type 


Attribute Type 


Match Value 


Filters 


Initial Substring 


Substring 


Final Substring 


License Request 



LL 
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Filter { 

Filter-Type AND 
Filter-Item { 

Filter-Item-Type SELECT 

Attribute-Type Product-Use-Authorization 

Filter { 

Filter-Type AND 
Filter-Item { 

Filter-Item-Type SELECT 
Attribute-Type Calling-Authorization 
Filter{ 

Filter-Type AND 
Filter-Item { 

Filter-Item-Type EQUALITY 
Atribute-Type Producer 
Match-Value "Digital" 

} 

Filter-Item { 

Filter-Item-Type EQUALITY 
Attribute-Type Producer 
Match-Value " Amazing Database" 

} 

} 

i 

Filter-Item { 

Filter-Item Type EQUALITY 

Match-Value "Digital" 

} 

Filter-Item { 

Filter-Item-Type EQUALITY 
Attribute-Type Issuer 
Match-Value "Digital" 

} 

Filter-Item { 

Filter-Item-Type EQUALITY 
Attribute-Type Product-Name 
Match-Value "Amazing Graphics System" 

) 

} 

} 

} 



FIG. 46 Example Filter Value Notation 
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DETDEN The license data header, called LicenseDataHeader , is represented as a 
syntax diagram in Figure 17. The license-id field 

provides a potentially unique identification of the encoded license 
data, so issuers of license data can generate unique license- 
ids to distinguish each issuance of license data; however, the 
architecture does not require this to be the case, since the. 
only architectural restriction is that no two objects in any single 
license management domain may have the same value for license- 
id. The licensee field identifies the party who has received the 
rights reflected in the license data,- there are at least. 
The license ID element uniquely identifies the 

license data it is associated with, and is described by the syntax 
diagram of Figure 3 3.. v 
fhe . . . Although technology may not exist to detect the 
interorganizational boundaries of a wide area network (i.e., what is oi 
the Internet as opposed to being on a company's own network), 
the assumption is that interorganization and internetwork sharing of 
licenses will. 



